.NET RIA Services Twitter Pitch

A key value proposition is the ability to think of your RIA as a logical extension of your server, i.e. its part of the same application, a rich projection to some extent, rather than a separate applications. Based on that perspective, .NET RIA Services prescribes a pattern, centered around a class called DomainSevice, that allows you to work with data, esp. in an n-tier context, in an end-to-end manner (quering, editing, creating units-of-work, validation, conflict handling, offlineability etc), by structuring the queries and operations you want to expose, and describing the semantics and intent with things like validation, and authorization rules as well as visualization hints metadata and shared code. Additionally you also get to benefit from out-of-box higher level application services like authentication, authorization, user settings, and with more to come in the future.

OK, so now you’re interested (hopefully), and might wonder more about what is this DomainService thing that I alluded to. You might ask me to do an email writeup (someone actually did exactly that yesterday). Here is a bit of what I wrote in my reply:

An app developer authors a DomainService to encapsulate their application/business-logic (validation, authorization and rules, triggering workflows etc) by implementing a logical group of CRUD and custom operations that together define a particular function of their application (eg. a catalog, purchase order system etc). A DomainService exposes this functionality to one or more presentation layers (eg. Silverlight, ASP.NET, Ajax etc.) or to a service tier (eg. WCF, ADO.NET Data Services), and in turn encapsulates an underlying DAL or data model. It also exposes a presentation model by virtue of the operations it defines. This presentation model might include portions of the underlying data model, but is primarily a separately designed model suitable for use by the presentation tier. Most DomainService implementations will not just be an indirection and pass-through layer to the DAL they encapsulate - instead, they will contain a bunch of meaningful code that is unique to the application.

We had some key requirements and constraints when coming up with the pattern and the DomainService infrastructure:

• DAL agnostic - we don’t want to create yet another DAL. More importantly we want to allow developers to leverage their DAL of choice and its specific capabilities, whether its direct db access using something like ADO.NET, Linq To SQL or EF, or indirect through repositories or services. You might not even work against a database in a classic sense. You might be working against a workflow, or any source for data in the truly general sense (eg. Active Directory, the current process list, etc. etc.)
• DAL encapsulating - the next tier consuming the DomainService shouldn’t need to know about the particular DAL choice, thereby enabling the developer can completely switch DALs at a later date.
• Reusable - the application logic you write within a domain service is a key asset you’ve invested in. It needs to be reusable in different contexts and different presentation requirements you might have.
• Testability - given a DomainService is an interesting asset, one should be able to independently unit test the domain service by mocking out the DAL and its other dependencies. From a separation of concerns perspective, it encapsulates the app logic, and doesn’t take on things like persistence, serialization etc.

And finally, if you really want to look deeper into the architecture with some pictures, I’d point you at my blog post on the high level vision and architecture of .NET RIA Services. Along with that are links to Brad’s blog, where he has been cranking out samples, and the official bits+doc download. Note: do check out the doc, which was the result of joint effort of folks on the product team.