让你了解.NET RIA Service

As was to be expected there were lots of announcements around Silverlight at the last MIX conference in Las Vegas. One particular product announcement is very interesting for Line Of Business (LOB) application developers. This big announcement is all about the .NET RIA Services.

What are .NET RIA Services?

RIA, short for Rich Internet Applications, is a bit of an umbrella term for all sorts of applications delivered through the browser. The key aspect however is that they deliver some business function and are not just about flashy graphics. Business applications tend to work with data and other business resources so they are usually built in the standard N tier architecture. If we take a look at this N tier architecture for the most common type of business resource, the database, we typically see the Create, Read, Update, Delete, (CRUD) pattern appear all the time. While implementing the CRUD pattern in Silverlight isn’t extremely difficult the very fact that the Silverlight application runs in the browser without direct database access and all server communication is done asynchronously makes this harder than it needs to be. This is exactly one of the problems the .NET RIA Services is trying to solve. Of course there is more to the .NET RIA Services and the standard CRUD operations is just one of the issues addressed. As we will see in this article it addresses much more by including things like data validation, general communication, keeping client and server code synchronized and more.

When evaluating the .NET RIA Services we should be looking at it from two different perspectives. First of all it is a set of design guidelines of how to create a RIA style application. Secondly it is a series of .NET libraries and Visual Studio templates implementing the design guidelines. So even if you don’t want to use the .NET RIA Services binaries, studying the design is very useful for a Silverlight line-of-business (LOB) developer. Another thing to keep in mind when evaluating the .NET RIA Services is that it is not just about Silverlight but more general. The first samples may be with Silverlight clients but a client could equally well be written in ASP.NET/JavaScript, WPF or any other client that can call WCF services.

Some of the problems the .NET RIA Services tries to solve

When developing Silverlight LOB style applications developers today are faced with a number of challenges not directly related to the business problem they are trying to solve. Some of the problems a Silverlight RIA developer faces include:

• Both the server and client side logic need to be developed together but both are very separate from each other. Often when the server side code has been updated the developer must manually update the WCF service reference so the client side code is aware of the changes.
• It is not possible, at least without some trickery, to use an assembly both in a regular .NET and a Silverlight assembly, making it hard to share code between the client and the server.
• Using WCF to communicate to the server. The asynchronous nature of WCF, or all external communication for that matter, when used inside of Silverlight is an extra complicating factor.
• Data entered needs to be validated both on the client, for immediate UI feedback, and again on the server, for security purposes.
• The server has to be secured to prevent unauthorized use by other than the intended client application.

All of these are common problems but really not related to the actual business problem we are trying to solve. The .NET RIA Services tries to solve these problems for us making it easier to develop LOB applications in Silverlight.

Some of the techniques the .NET RIA Services uses to solve these problems.

• The .NET RIA Services lets us work in such a way that the server and client parts of our application are two sides of one single application. This means we are not working in a Service Oriented Application (SOA) style with a very disconnected application. Instead the .NET RIA Services sees both parts of the application as one that just happens to be split into parts by the network.
• Automatic, compile time, code generation is used to connect the client with the server parts of the application. No need to manually set a service reference or update it.
• By using file naming conventions code written in the server part of the application can automatically be inserted into the client part of the application. Again no need for the developer to do anything except use a simple naming convention.
• Most of the WCF communication is completely hidden from the developer and for the most part there is no need to worry about the fact that all communication is asynchronous.
• Data validation rules are added to the entity classes in the server part of the code. These are automatically added to the client part and evaluated in both parts of the application.
• The standard simple declarative security model we are all already familiar with can be used.

The main thing to remember when evaluating the .NET RIA Services is that it is not intended for SOA style applications where the service and the client are very loosely coupled. Where it is intended to be used is where the client and service are tightly coupled; just like in desktop client/server applications, only in this case the client and server parts of the application are separated by an internet or intranet connection.