Yesterday at Mix we announced .NET RIA Services… We are very early in the development cycle for .NET RIA Services and we are eager to get your feedback and thoughts.
The marketing blurb catches the key points:
Microsoft .NET RIA Services simplifies the traditional n-tier application pattern by bringing together the ASP.NET and Silverlight platforms. The RIA Services provides a pattern to write application logic that runs on the mid-tier and controls access to data for queries, changes and custom operations. It also provides end-to-end support for common tasks such as data validation, authentication and roles by integrating with Silverlight components on the client and ASP.NET on the mid-tier.
(shamelessly stolen from Nikhil’s talk)
Our thinking on the RIA Services work really grow out of the LINQ project a few years ago. LINQ integrates query semantics into the languages (C#, VB, etc) providing a common abstraction for working with data; whether that data is in memory CLR objects, XML, relational data, or anything else. With RIA Services we are extending this pattern by offering a prescriptive model for exposing your domain logic over LINQ. We think of domain logic as that part of your application that is very specific to your domain – that is the particular business problem you are solving. By following this pattern we are able to provide a number of features that help you focus on your domain logic rather than the plumbing in your code. For example, we offer a great way to write application logic on the server and display, validate the data, as well as supporting authorization, querying, sorting, filtering, paging, etc, not to mention providing a clean way to mock out the data layer to do testing (a la TDD, etc). All regardless of what data store you use (Entity Framework, Linq2Sql, nHibernate, Xml file, REST service, WCF-server, etc).
We think this pattern is useful in a wide verity of application types… a couple that we are talking a lot about here at Mix09:
N-Tier Access – By following the RIA Services pattern, we can make it very easy for you to build out a n-tier silverlight or AJAX application. We aim to make it nearly as simply as building traditional 2 tier applications. In this space, you should think of RIA services as a more perceptive layer on top of ADO.NET Data Services and WCF. For the data querying and updating aspects of the model we will be using ADO.NET DataServices… this means that you will be able to just “Add Web Reference” to your domain logic and get the standard REST and JSON based access that ADO.NET DataServcies offers. We also expect to eventually provide full access to all the power and flexibility from the underlying WCF services such as highly optimized binary serialization.
Another great benefit of this model is that you can use it directly within your ADO.NET Data Services. We believe this provides a more productive way of writing your domain logic than using the current interception-based patterns. We are hard at work on this now, look for this in a future CTP.
ASP.NET Access – By following the RIA Services pattern, you will also be able to build ASP.NET applications easily while taking advantage of all the built in features of RIA Services such as data validation, authorization, etc. In the March preview, we are offering a asp:DomainDataSource control that enables very easy ASP.NET WebForms access to your domain logic. Building on top of that is a future version of ASP.NET Dynamic Data that makes it very easy to generate common, standard UI based on your domain logic.
Back in Redmond, we are working on provide a very clean access to your domain logic via ASP.NET MVC. The pattern here is very cool, and I can’t wait to talk about it in a future CTP.
If you combine the verity of data sources with the variety of presentation options we are aiming for with .NET RIA Services…
What what is in the .NET RIA Services March ‘09 Preview?
I highly recommend going through the detailed walkthrough that we have
But few the geeky among us, let me break down what we have in the package by assembly…
Enhancements to the .NET Framework on the Server:
System.Web.DomainServices.dll – This assembly contains the core DomainService classes that handle the validation, query, etc.
System.Web.DomainServices.Providers.dll - the LINQ2SQL and EF provider… we hope between us and the community to provide much more in the future such as Azure, Dataset, nHibernate, etc
System.Web.DomainServices.Tools. dll – the VS support for building DomainServices
System.Web.DomainServices.WebControls. dll – the ASP.NET support for DomainServices (asp:DomainServiceDataSource and friends)
System.Web.DynamicData.dll – Update to the ASP.NET Dynamic Data support to work with Domain Services.
System.Web.Ria.dll – RIA Specific services such as authtication, user profiles, etc.
System.ComponentModel.DataAnnotations.dll – Updates to the .NET Framework 3.5 SP1 set of data annotations. This is shared with Dynamic Data.
Microsoft.Web.Extensions.dll – Some additional support for patterns such as SEO, these will be folded more deeply into the platform in future previews.
Enhancements to Silverlight on the client (other clients such as WPF and Ajax coming soon)
System.Windows.Ria – Client data model for the DomainService.. handles change tracking, validation, etc
System.Windows.Ria.Controls.dll – DomainDataSource control that provides Xaml based control for accessing DomainService (layers on top of the client data model).
Again, we are early the development cycle for RIA Services and we’d love your feedback and thoughts on the model!
Please let me here your thoughts!