Practical ASP.NET

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

Peter returns to .NET RIA Services to look at the client side of creating an application.

• By Peter Vogel
• 07/29/2009

In last week's column, I looked at .NET RIA Services and spent some time on the server-side, ASP.NET part of the technology. This week, I'm going to look at the client-side, Silverlight portion.

In .NET RIA Services, you create a Silverlight application with a linked ASP.NET Web application. In the ASP.NET Web application, you can have one or more Domain Service classes whose methods return server-side objects. The methods you add to your Domain Service class will cause equivalent methods to be generated in the Silverlight client that will call your server-side methods through Web services calls. Unfortunately, the objects returned from a Web service can't/won't have the Silverlight 3 attributes that support databinding and validation.

Integrating Silverlight
.NET RIA Services lets you add those attributes through a metadata file. If you create a Domain Service class in your Web Project called, for instance, CustomerService.vb, then you can create a second file called CustomerService.metadata.vb. In the metadata file, you can add a description of the interfaces of the classes returned by your Domain Service methods.

In the metadata file, you can decorate the items in the interface (classes, methods, properties) with the Silverlight 3 attributes you want. When the equivalent class is generated in the Silverlight client, those classes will have the attributes you specified in the metadata file added to them. There's an important distinction here, by the way: The objects returned by your server-side methods are not what appears in the Silverlight client; what appears are auto-generated objects equivalent to the classes returned by your methods. It's those classes that will pick up the Silverlight attributes.

I have to admit that this process looks a little "hinky" to me because components are tied together by having the right file names. But it's also very extensible; as new attributes are added to .NET, you can add the ones you want to your Silverlight client-side objects through the metadata file.

Issues
This early in the process, it seems petty to cavil about what isn't present. One of the goals of .NET RIA Services is to simplify Web development (what Microsoft calls "democratizing" development). So some options that I would like to see may not be realistic within that constraint. On the other hand, these features may indeed be present and I just haven't found them yet.

In the Silverlight client, when you call the client-side equivalent of a method, the method doesn't hand you back an object or a collection of objects. Instead, after calling the method, you access the retrieved objects through a property on the class that represents your Web service. This design means that maintaining, for instance, two lists of Orders (one list for each of two customers) is awkward because there's only one instance of the property for any class. I'd prefer to see the client-side code implement the Factory method pattern.

While the Silverlight application has an automatic connection to the methods defined in the Domain Service class, no other client can access the methods. From a SOA point of view, it would be convenient if the services created for this application appeared as Web services that could -- at least in theory -- be shared with other clients.

It doesn't appear that the classes created in the Silverlight application can be extended. It doesn't appear that you can create a partial class for the client-side Silverlight objects and use those partial classes to add the interface to the auto-generated classes.

However, all this is minor sniping at a technology that's still in its infancy -- and may, in fact, only reflect my ignorance. I think the technology looks very cool, indeed.