Data-centric Architecture with Silverlight

Silverlight can be used to build line-of-business and other data-centric applications. This type of application typically involves the following steps:

Get the data from the server.
Display and edit the data on the client.
Submit the changes back to the server.

Steps 1 and 3 typically rely on Web services to transfer the data and traditional data access strategies to query and update a database. Step 2 typically involves Silverlight data-bound controls.

Microsoft offers many tools that can be used to perform the server-side part of the job. The latest such tool is ADO.NET Data Services, which provides Web-accessible endpoints for data models and integrates with Silverlight through the ADO.NET Data Services for Silverlight library (System.Data.Services.Client.dll). A lot has been written lately about this new technology (see for example "Data Services" in MSDN vol. 23, no. 10, September 2008).

ADO.NET Data Services is a powerful new technology that is likely to become a standard for many types of data-centric applications. However, it's not the only option. The traditional data ADO.NET classes (DataSet, DataTable, DataAdapters, and so on) can also be used to retrieve and update data on the server. These classes have been used by developers since .NET 1.0. They are solid, powerful, and easy to use. Furthermore, many developers already have a considerable investment in the form of code that has been used and tested for a long time.

ComponentOne Data for Silverlight is a set of classes that can be used by Silverlight clients to exchange data with servers using traditional ADO.NET. The typical steps are as follows:

Get the data from the server.
1. Server populates a DataSet object the traditional way (typically using DataAdapter objects to retrieve the data from a SqlServer database).
2. Server calls DataSet.WriteXml to serialize the DataSet into a stream and sends the stream to the client.
3. Client uses the DataSet.ReadXml method to de-serialize the stream.
Display and edit the data on the client.
1. Client binds the tables in the DataSet to controls (possibly using LINQ queries).
2. User interacts with the controls to view, edit, add, and delete data items.
Submit the changes back to the server.
1. Client calls DataSet.GetChanges and DataSet.WriteXml to serialize the changes into a stream and sends the stream to the server.
2. Server calls DataSet.ReadXml to de-serialize the changes, then uses DataAdapter objects to persist the changes into the database.

The role of C1Data in this scenario is twofold. First, it provides a symmetric serialization mechanism that makes it easy to transfer data between DataSet objects on the client and on the server. Second, it provides a familiar object model to manipulate the data on the client.

Note: C1Data does not compete against ADO.NET Data Services. It allows you to leverage your knowledge of ADO.NET and assets you may already have. You can transfer all that to Silverlight with minimal effort, and migrate to ADO.NET Data Services gradually, if such a migration is desired.

C1Data is not a legacy technology. You can use it with LINQ, for example. In fact, C1Data enables LINQ features that are available on desktop but not in Silverlight applications (partial anonymous classes).

The next sections describe the implementation of a simple application that performs the steps described above. Despite its simplicity, the application shows how to perform the four CRUD operations (Create, Read, Update, Delete) that are required of most data-centric applications.