Multiple consumers, single data provider - Too Early For RIA? Options?

Question

I have a few projects coming up that have a number of endpoints or clients that can hit the same data. For instance a site might have...

• A asp.net MVC based end user facing website
• A web based adminitration back end that can allow specific, limited updates from some users in situatiosn where a full client isn't useful (mobile web etc)
• A full on rich client for administration so we can use touch and other techniques to really make the user experience for content management shine - these may be silverlight or full on WPF apps, as needed

The question is... whats the best way to connect all that? Right now I use a multiple project split for the MVC.

• ProjectName.Core - this project has all the common models, all the repository classes and all the helper classes
• ProjectName.Web - an MVC project that references the Core to pull in the repositories and models it needs
• ProjectName.Admin.Web - another MVC project dedicated to the admin interface that references the Core to pull in the repositories and models it needs (which will ultimately live on a seperate subdomain from the end user facing site)

Then the story peters out int he sense of clear guidance. When the time comes to build a WPF / Silverlight project to hit the data I can do one of the following to the best of my understanding now...

• Convert the "Core" to provide a RIA style DomainService, and attempt to alter the MVC projects to make use of it. However there is little guidance on using MVC with RIA, RIA is in its infancy AND the WPF to RIA story is also still only thinly documented
• Do the same as above, but using WCF. However WCF prings with it async complexity that I really want RIA to hide for me.
• Fall back 20 yards and just bolt plain old web services onto the Core on top of the Repositories and Models I already have. This seems... old school :)

Any thoughs and input are welcome including pointers to examples and documentation. I want to make the best decisions I can now, and am coming up to speed fast on RIA and WCF so I can but community input is always helpful.

Thanks!

Answer 1

Take a look at ADO.NET Data Services (formerly known as Project “Astoria”).

On my way to work today I was listening to a .NET Rocks! podcast, "Stephen Forte on Data Access Options", and they very excited about this, especially for scenarios like the one you describe. It's interesting stuff, and something I would check out sometime very soon.

Answer 2

I think there's something to be said about plain old WCF services, these can make use of your domain services and repositories and expose a model more appropriate for services. Too often I've found that simply exposing the domain model on the wire ends up with a duplication of logic on both the client and the server.

My advice would be for some sort of service layer, this has the logic of shaping your domain model into appropriate types for the wire. \

Ideally I'd like to be able to share my Domain Services between the client (WPF / Silverlight) and the server (ASP.NET MVC) and have different underlaying repositories (Linq to NHibernate / Astoria). Difficult with the asynchonous nature of Silverlight.

Answer 3

For the curious, it certainly looks like RIA Services is the win here. Build a single DomainService then consume it everywhere. Brad Abrams covers a lot of this ground at bit.ly/94fFx - it really helped.