Practical ASP.NET

Technology To Think About: .NET RIA Services on the Server

The ASP.NET-related portions of .NET RIA Services aren't ready for primetime yet, but now's a good time to start kicking the tires.

• By Peter Vogel
• 07/22/2009

A few months ago, I wrote an article on Silverlight 3 for Visual Studio Magazine, the point of which was to show how new features in Silverlight 3 allowed developers to decorate their client-side objects with lots of new attributes that supported standard business-related activities (primarily databinding and data validation).

In a sidebar, the article mentioned that .NET RIA Services combines Silverlight and ASP.NET. And that's true. Sort of.

To fully take advantage of Silverlight's data support, you have to create Silverlight client-side objects -- which aren't the objects returned by any Web service. So when retrieving data in my sample application, I had to create and initialize a client-side object for each of the objects I retrieved from a Web service. Not only was that annoying, that code was virtually identical in every application. And I hate writing the same code over and over again.

I also had to create two applications: a set of server-side Web services (to provide server-side data access and updates) and the client-side Silverlight application (to call the Web services and interact with the user). I then had to wire them up. More boilerplate code.

Being a big fan of code generation, I was already considering how I could get Visual Studio to generate, at least, the code to wire up the Silverlight client and my Web services for me. But .NET RIA Services takes care of that.

Writing the Mechanical Code
The goal of .NET RIA Services is to support, simplify and extend the process of creating Silverlight applications that access server-side resources. .NET RIA Services is obviously still a work in progress (here's where, as of June 9, you can see the roadmap which has a release-to-Web date, or RTW, in the "first part of 2010"). You can, however, download a preview (notice: not even a CTP) here.

With .NET RIA Services installed, when you create a Silverlight Application project, you get the option to "Link to a ASP.NET Server Project." If you take the option, Visual Studio generates two projects: an ASP.NET Web Application Project (with the usual pages to host your Silverlight application and class file) and a Silverlight Application linked to the ASP.NET application. If you check the Properties window for the Silverlight project, you'll find that the Application tab has an "ASP.NET Server Project link" drop-down list that's set to the name of the Web project in the solution.

The nature of that link is what simplifies the process. As you add new methods to specific classes in your ASP.NET project, corresponding methods to call your Web services are generated and added to the Silverlight application. Rather than building two applications that you need to wire together, you write server-side methods and use them -- or versions of them -- from your client-side code.

Do be aware, though: There's a funny naming convention in place wherein if your Web service method name begins with "Get," the generated client-side method will begin with "Load" (i.e., GetCustomers on the server is called from LoadCustomers on the client).

The specific type of class that you need to add your methods to is called a Domain Service class. As part of adding a Domain Service Class to your project, you can tie it to an Entity Framework ObjectContext (or LINQ DataContext). This will cause the Domain Service to be created with some methods already defined for you based on the entities in your model. However, creating a Domain Service class from scratch isn't hard; it's just a Class file with the EnableClientAccess() added to the Class declaration .

It's the creation of the Domain Service class that leverages your ASP.NET skill -- along with whatever enhancements you want to make to the ASPX page hosting the Silverlight application. While it's true that these changes are made in an ASP.NET project, it's not really ASP.NET development. Most of your coding will, presumably, be business logic-related or will call out to server-side business objects. Some ASP.NET-specific knowledge will be useful in using server-side resources (e.g., caching and other state management tools.

The Silverlight side of the story is also interesting...but I'll look at that next week.