Using RIA Services requires you to follow a pattern in structuring your application. First, your server (web) project and your client (Silverlight) project must be linked so that the RIA Services build task/code generator can project code from the server project onto the client project and create the supporting objects used to interact with the server. This means that both your client and server projects must exist in the same solution.

The next step is to create one or more domain services. Think of a domain service as much like a standard WCF service, but following a given pattern (and consisting of some base functionality).

The RIA Services build task automatically generates code in the client project that enables it to interact with the domain service on the server. It creates a domain context for each domain service, and proxy classes for each of the entities exposed by the domain service.

On your domain service you create domain operations, which will typically expose data to the client and accept changes in a create, read, update, and delete (CRUD) pattern.

The entities in the server project that are exposed by the domain operations can be decorated with attributes (such as specifying data validation rules), either directly or by applying the attributes to associated classes (known as metadata classes) that enable you to apply attributes to the entities without modifying them directly (important when the entities are code generated, such as Entity Framework entities that can't or shouldn't be modified directly). You can share code between the server and the client projects by simply placing the code to be shared in one or more files with the .shared.cs extension.

Once this is set up on the server and you are exposing data from your domain services, you can turn your attention to the client project in order to call the operations on the domain service and consume the data. You can do this in code by creating an instance of a domain context and calling the exposed operations. Alternatively, you can make use of the DomainDataSource control to interact with a domain service declaratively in XAML.

Entities are generally exposed from a domain operation via an IQueryable<T> expression or as an IEnumerable collection. By returning an IQueryable<T> expression, the power of the RIA Services framework is demonstrated in that you are able to write a LINQ query on the client specifying how you want the resulting entity collection filtered, sorted, grouped, and paged. RIA Services serializes the LINQ query and sends it to the server, where it is appended to the query expression returned from the query operation before it is executed. This enables the collection to be filtered/sorted/grouped/paged on the server without requiring the entire collection to be sent back to the client first (minimizing the required data traffic).

As this collection is updated on the client, the domain context that exposes it maintains a changeset, which includes the entities that have been inserted into, deleted from, or updated in the collection. Changeset management is another extremely powerful feature of the RIA Services framework that greatly simplifies managing the collection and sending updates back to the server. The SubmitChanges method on the domain context will send the changes made to an entity collection back to the server (which based on the changes made will automatically call the insert/update/delete operations to update the back-end database accordingly, plus any custom operations that were called) as appropriate.

This discussion should have given you a broad overview of the process of working with RIA Services and introduced you to some of the key concepts. The next section looks at how to actually put these concepts into practice.

Throughout this book you'll be creating a business application in Silverlight for a fictional bicycle sales chain called Adventure Works Cycles, which will enable employees to manage the various aspects of the business, including product inventory, sales, and purchasing. For this we'll be using SQL Server 2008 as our database server (the free Express version installed with Visual Studio will be sufficient), and the database that will be supporting this scenario will be the AdventureWorks2008 OLTP sample SQL Server database from Microsoft, which you can download from http://msftdbprodsamples.codeplex.com. This database has been chosen because it is an example of a typical business database with a suitably complex structure, and is also well populated with sample data.

In order to retrieve and persist data to the database, we'll be using the Entity Framework as our data access layer. The Entity Framework is an object-relational mapper (ORM) that enables you to create a conceptual object model (known as an entity model) and map it to the database schema (e.g., tables, views, and stored procedures). You can then query this object model in code using LINQ to Entities (LINQ specifically designed for querying an entity model).

The Entity Framework takes care of translating the LINQ to Entities queries to SQL queries in the database, and returns the data as the objects that you've defined in your model. Essentially, the Entity Framework makes working with database data in code a much more pleasant and robust experience, as it enables you to work with the data as objects and collections (instead of rows and tables), and to write strongly typed queries against the entity model.

The Entity Framework has been subjected to some controversy since its initial release, including a vote of no confidence petition signed by many prominent members in the developer community (including a number of Microsoft MVPs). It has undergone numerous improvements since then (with the .NET Framework version 4) to counter the issues that were raised with the first version, and is working its way toward becoming a robust yet easy-to-use ORM.

One of the benefits of using the Entity Framework for this project is that RIA Services has been designed to work very smoothly in conjunction with it, enabling services with the standard CRUD operations to be created very easily for given entities.

However, the Entity Framework is by no means the only data access technology supported by RIA Services—it also has support for LINQ to SQL models (which can be found in the WCF RIA Services Toolkit, discussed later in the chapter), and in fact it can work with any data source (although doing so involves a degree of additional work when creating a domain service). So if you have an existing data access layer to access your database, or you want to use a different ORM (such as nHibernate), RIA Services can also support these scenarios.

In fact, employing the built-in support for exposing entities directly from your Entity Framework model could in some ways be considered bad practice. While taking advantage of this support to expose given entities to the client makes creating and maintaining services incredibly easy, the entities are essentially a model of your data layer, and ideally these entities should not be exposed to the presentation layer. Whether or not you pass entities or plain-old CLR objects (referred to as POCOs, but also known as presentation model types in RIA Services) of your own design back and forth is a decision you will have to make, dependent on many factors. Using entities will make development much faster, but will also be less flexible than using custom presentation model types. RIA Services works just as well using presentation model types as it does with entities, despite more work being involved in initially creating the domain services. Therefore, the best practice would be to use presentation model types as the data transfer mechanism (which can be populated with data from your entity model), although we will take a look at both of these methods (starting with directly exposing entities because they provide the easiest and fastest means to get started).

Once you've installed the database you can create your entity model. This is a very straightforward process, as the Entity Data Model Wizard will guide you through this process.

Add a new item to your Web Application project, select the ADO.NET Entity Data Model item template, and name it AdventureWorksModel.edmx. Following through the wizard steps, you want to create a model from a database, create a connection to the database, and select the tables in the database to be included in the model. This chapter will demonstrate exposing product data, so select the Product table to be added to your entity model. You can add other tables from your database to your entity model at a later time if you wish.

Ensure that the Include Foreign Key Columns in the Model check box is selected, as this will greatly simplify dealing with foreign keys in scenarios where an entity is being updated and combo boxes are enlisted to select an item from a dictionary and assigned to a property on the entity.

When you click the Finish button, the entity model will be generated and displayed in the entity model designer.

Let's take a quick look at how a domain service works and the various phases in its life cycle. The core interaction that a client has with a domain service is to retrieve a collection of objects (or a single object) from the domain service, and return any of the objects that have been modified, or additional objects that have been inserted into the collection back to the server to update the database accordingly (i.e., the create/update/delete in CRUD). The objects in the collection that have been changed (inserted/updated/deleted) are tracked on the client and returned back to the domain service, together with the domain operation that should be applied to each object on the server as a changeset (when the SubmitChanges method is called on the domain context associated with the domain service that was created in the client project).

This calls the Submit method on the domain service, initiating the start of the domain service's life cycle. The domain service will work through the following phases in order:

Each of these phases is automatically performed by the domain service; however, there is a corresponding method on the domain service that you can override and hook into if you need to provide some custom behavior in addition to what is provided by the base domain service class. These methods are

You can also override the Submit method, which encompasses each of these phases in order to hook into that, too. While in a phase, the logic for that phase will be run over every object in the changeset. If an exception is thrown on any of these objects (during any of these phases), then the entire changeset submission will be cancelled.

Let's work through the process of exposing a Product entity from the entity model. The first step is to add a domain service to your web project.

Add a new item to the Services folder in your web project, using the Domain Service Class (under the Web category) as the item template. We will be using this service to serve up product data, so we'll call it ProductService.cs. This will initiate the Domain Service Class Wizard, as shown in Figure 5-4.

Figure 5.4. The Domain Service Class Wizard dialog

Select your AdventureWorks2008 entity model from the Available DataContexts/ObjectContexts drop-down list (if it isn't already selected). This will display each entity in your entity model in the list.

Let's now take a look at each element of this dialog and what it does.

A query operation enables you to expose data to a client. This data may be either a collection of entities/objects or a single entity/object. Let's look at each of these cases separately.

public IQueryable<Product> GetProducts()
{
    return this.ObjectContext.Products;
}

public IQueryable<Product> GetProducts(string nameFilter)
{
    return this.ObjectContext.Products.Where(p => p.Name.StartsWith(nameFilter));
}

public Product GetProduct(int productID)
{
    return ObjectContext.Products
        .Where(p => p.ProductID == productID)
        .FirstOrDefault();
}

When a client application submits a changeset to the server, RIA Services will call the appropriate insert/update/delete operation for each entity in the changeset, based on the action specified for that entity in the changeset. These operations cannot be called explicitly from the client.

public void InsertProduct(Product product)
{
    if (product.EntityState != EntityState.Added)
    {
        if (product.EntityState != EntityState.Detached)
        {
            this.ObjectContext.ObjectStateManager.ChangeObjectState(product,
                                                                EntityState.Added);
        }
        else
        {
            this.ObjectContext.AddToProducts(product);
        }
    }
}

public void UpdateProduct(Product currentProduct)
{
    if (currentProduct.EntityState == EntityState.Detached)
    {
        this.ObjectContext.Products.AttachAsModified(currentProduct,
                                this.ChangeSet.GetOriginal(currentProduct));
    }
}

public void DeleteProduct(Product product)
{
    if (product.EntityState == EntityState.Detached)
    {
        this.ObjectContext.Attach(product);
    }
    this.ObjectContext.DeleteObject(product);
}

An invoke operation is a nonspecific domain operation, and behaves the same way as a service operation in a standard WCF service. As a general rule, invoke operations don't return or act upon entities. They either initiate an action on the server (e.g., requesting the server to send an e-mail) or request data from the server, which returns a simple value or data for which changeset tracking is not required (e.g., requesting the current currency exchange rate).

Like query operations, invoke operations are methods that the client application can call directly. These operations are called immediately (unlike custom operations, which are queued and only called when a changeset is submitted to the server).

public decimal GetExchangeRate(string fromCurrency, string toCurrency)
{
    return ExchangeRates.GetRate(fromCurrency, toCurrency);
}

Custom operations are operations that perform an action on an entity. For example, you might have an operation that discontinues a product, with all the logic to do so to be performed on the server. However, whereas an invoke operation is called immediately from the client, custom operations have their execution on the server deferred until the client submits a changeset to the server (hence treated in the same way as insert/update/delete operations).

When a custom operation is generated in the client project, it will be created as a method on the entity that it acts upon. In addition, it will also be created as a method on the domain context associated with the domain service.

public void DiscontinueProduct(Product product)
{
    // Logic to discontinue the product...
}

As previously described, metadata classes enable you to decorate your entity with attributes without actually modifying the entity class itself (useful when you code-generate your entities and a regeneration re-creates the entity class). A metadata class is associated with your entity via an attribute on the entity class that points to it. In order to not have to modify the entity class to apply this attribute, the usual method is to create a partial class for the entity and apply the attribute to it instead.

Open up the metadata class that was created for the Product entity (from your Entity Framework model) to see how it is structured. The file name for metadata class files are generally of the form <DomainServiceName>.metadata.cs.

This file contains a partial class that extends the Product entity. This is merely so the MetadataType attribute can be applied to the entity, designating the corresponding metadata class.

[MetadataTypeAttribute(typeof(Product.ProductMetadata))]
public partial class Product
{
    internal sealed class ProductMetadata
    {
        // Field definitions (removed for the purposes of brevity)
    }
}

This attribute requires the type for the metadata class associated with this entity as its constructor parameter. As you can see from the example, it is associating the ProductMetadata class contained within the Product class (i.e., the ProductMetadata class is a nested, or inner, class of the Product class). This provides the link between the entity class and the metadata class, which is used by RIA Services to associate the two together. It's not essential to use a nested class as your metadata class—you can actually use a class anywhere that can be referenced, but by default the metadata classes created by RIA Services are created as nested classes. You can then treat the metadata class as if it were the actual entity class, and decorate it with the required attributes.

Note that the metadata class that was created by the Domain Service Class Wizard contains a public field representing each property on the associated entity, which you can decorate with attributes as required.

You may not necessarily want the entity that is created (by the RIA Services code generation) in the client project to be the same as the entity that is in your server project. For example, the entity may consist of properties that shouldn't be transferred to the client and/or made accessible to it (such as password properties, images, calculated properties, credit card numbers, etc.). Let's look at customizing what's generated on the client-side entity and what data is transferred to the client from the server.

public IQueryable<Product> GetProducts()
{
    return ObjectContext.Products.Include("ProductInventory");
}

[Include]
public EntityCollection<ProductInventory> ProductInventory;

One of the important problems that RIA Services tries to resolve is where validation logic needs to be written and executed on both the server and the client. Not only is it a duplication of code and effort to write the same logic in both places, but this logic can easily get out of sync (with a change being made in one place but not the other). It's important to execute the validation logic in both places because you want to have a responsive user interface (without waiting for the server to tell the user that something is invalid), but you also want to validate the data on the server because there is no guarantee that the data came from your own client application (and that its rules weren't circumvented). By enabling you to define your validation logic on your entities on the server, and automatically applying the same validation attributes when it generates the corresponding entities in the client project, RIA Services overcomes this problem. Your validation logic only needs to be written (and maintained) in a single location, and is kept synchronized by the code generation of the entities in the client project.

[Required]
[StringLength(50)]
[RegularExpression(@"(?<user>[^@]+)@(?<host>.+)")]
public string EmailAddress;

[Range(0, 150)]
public int Age;

public class ProductClassValidationAttribute : ValidationAttribute
{
    protected override ValidationResult IsValid(object value,
                                ValidationContext validationContext)
    {
        string productClass = value.ToString();
        bool isValid = false;

        string[] validClasses = new string[] { "H", "M", "L", "" };
        isValid = validClasses.Contains(productClass.ToUpper());

        return isValid ? ValidationResult.Success : new ValidationResult(
                                                      "The class is invalid");
    }
}

[ProductClassValidation]
public string Class;

public class SellDatesValidationAttribute : ValidationAttribute
{
    protected override ValidationResult IsValid(object value,
                                        ValidationContext validationContext)
    {
        Product product = value as Product;
        return product.SellEndDate > product.SellStartDate ?
            ValidationResult.Success : new ValidationResult(
                "The sell end date must be greater than the sell start date");
    }
}

[SellDatesValidation]
internal sealed class ProductMetadata

Decorating your entities (which are essentially middle-tier components) with information for the presentation tier is somewhat controversial—it can make creating forms in your application very easy (using the drag-and-drop features in Visual Studio 2010), but it blurs the line between the middle tier and the presentation tier. Ideally, the middle tier should know nothing about how the presentation tier will display the data. In any case, some attributes are available that enable you to provide presentation information on your entities—whether you use these attributes or enforce a strict separation of concerns is up to you.

The primary attribute used for this purpose is the Display attribute. The DataForm control (from the Silverlight Toolkit) uses this attribute (if available) when it is automatically creating a data entry form from an entity, and the DataGrid control uses it when creating a data grid with automatically generated columns. The Display attribute has a number of properties that suggest to the presentation tier how the property should be displayed. Some of these properties control the following:

A number of important miscellaneous data annotations don't fit in either of the previous annotation type categories, but are used to control how RIA Services manages the entity, or to provide information to the presentation tier on how this entity should be displayed.

Some of the more important data annotations used by RIA Services are as follows:

The first step is to create a standard class containing just the properties that should be transferred between the client and the server. As with the examples provided earlier with entities from the Entity Framework, you can decorate this class (either directly or using a metadata class) with validation rule attributes and such.

Note that one property (or more as required) must be decorated with the Key attribute to indicate that that value of the property uniquely identifies the object (otherwise you will receive a compilation error, because the changeset manager on the client cannot manage the changes without it).

For this example we will create a presentation model class named ProductPM with similar properties (although we'll use only a subset for the purpose of brevity) to our Product entity, but demonstrate exposing presentation model objects from a domain service instead of Entity Framework entities. This object will not have any knowledge of how it is populated or persisted—it will be handled in the domain service.

Here is the code for the presentation model class:

public partial class ProductPM
{
    [Key]
    [Editable(false)]
    public int ProductID { get; set; }

    public string Name { get; set; }
    public string ProductNumber { get; set; }
    public decimal ListPrice { get; set; }
    public DateTime ModifiedDate { get; set; }
}

Now we need to create a domain service so the client can retrieve a collection of these objects, and update/insert/delete objects in the collection if appropriate. Unfortunately, the Domain Service Class Wizard only generates the CRUD operations in your domain service when you are using entities from the Entity Framework or objects from a LINQ to SQL model—it doesn't allow you to select objects of other types (because the CRUD logic for these objects does not necessarily follow a specific model). Therefore, we must create the domain service ourselves from scratch.

Add a new item to your project (in the Services folder), named ProductPMService, using the Domain Service Class item template, and select <empty domain service class> from the Available DataContexts/ObjectContexts drop-down list in the Domain Service Class Wizard dialog. This creates an empty domain service to which we can add the required operations. Notice that the domain service inherits from DomainService, instead of the generic LinqToEntitiesDomainService class that the previous domain services (that served up entities from the Entity Framework model) inherited from (providing the base functionality for how the domain service would handle the entities).

[EnableClientAccess()]
public class ProductPMService : DomainService
{
}

Now we need to add the query operation to the domain service. Because the data is coming from a query to the Entity Framework model, we can still take advantage of the benefits of returning an IQueryable expression by projecting data from the Entity Framework model onto a collection of the presentation model objects, and returning this query from the operation. Therefore, the client can add any additional sorting/filtering/grouping/paging that it requires. The following code demonstrates how this is done:

[EnableClientAccess()]
public class ProductPMService : DomainService
{
    private AdventureWorks2008Entities context = new AdventureWorks2008Entities();

public IQueryable<ProductPM> GetProducts()
    {
        return from p in context.Products
               select new ProductPM()
               {
                   ProductID = p.ProductID,
                   Name = p.Name,
                   ProductNumber = p.ProductNumber,
                   ListPrice = p.ListPrice,
                   ModifiedDate = p.ModifiedDate
               };
    }
}

When executed, this expression will populate and return a collection of our presentation model object (ProductPM) to the client.

You can also implement the insert, update, and delete operations by taking the ProductPM object that will be passed into each one as a parameter, and manually updating the Entity Framework model with the changes accordingly.

Particularly when inserting (and sometimes updating) data on the server, you will want to return values that have been generated on the server back to the client (such as a primary key value generated by the database when inserting a row, or a timestamp value being used for row versioning in the database). You can do this using the Associate method on the domain service's ChangeSet object. Pass this method the presentation model object, the entity that was updated, and a callback function. Once the database has been updated, the callback function will be called, at which point you can update the presentation model object as required from the entity.

The following code demonstrates updating the ProductPM object with the ProductID assigned to the Product entity when inserting a new record into the database:

public void InsertProduct(ProductPM productPM)
{
    Product product = new Product();
    product.Name = productPM.Name;
    product.ProductNumber = productPM.ProductNumber;
    product.ListPrice = productPM.ListPrice;
    product.ModifiedDate = DateTime.Now;
    context.Products.AddObject(product);
    context.SaveChanges();
    ChangeSet.Associate(productPM, product, UpdateProductPMKeys);
}

private void UpdateProductPMKeys(ProductPM productPM, Product product)
{
    productPM.ProductID = product.ProductID;
}

[Include]
[Association("ProductPM_ProductInventory", "ProductID", "ProductID")]
public IEnumerable<ProductInventoryPM> ProductInventory { get; set; }

To appropriately handle this type of scenario, you will need to create (and design) a strategy to identify, handle, and resolve these concurrency violations, on both the server and the client. RIA Services uses optimistic concurrency (i.e., the record in the database isn't locked from being updated by other users after being retrieved), so you will need to design your strategy within these boundaries. Optimistic concurrency violations are generally identified by comparing given properties on the original version of an entity (before it had been modified on the client) with those on the stored version of the entity (as it currently exists in the database), immediately before persisting data to the database. Therefore, concurrency checks generally involve three versions of the entity:

For example, a common strategy to identify concurrency violations is to have a column on your database table that is updated whenever the row is changed. Common column types for this purpose include

When performing an update operation on an entity, RIA Services will retrieve the entity as it is currently stored in the database and compare the original value of the given concurrency check property sent back from the client with its stored value as found in the database. If the values are different, then a concurrency violation has been identified. A possible reason the value of this property might have changed since it was retrieved from the database is if another user has updated the entity since the original version had been retrieved from the server.

Alternatively, if you don't have a single property on the entity that you can use for concurrency checks, then you may compare a number of (or all) properties on the entity between its original version and the stored version, and raise a concurrency violation if any of the values are different. This method is far more cumbersome than the single-column method, although it does let you pick and choose which properties whose changes you don't want to be lost, while ignoring changes to others whose changes may be unimportant.

By default, RIA Services (and the Entity Framework) will simply update an entity without performing any concurrency checks. You will need to configure it to perform these checks before updating/deleting data in the database.

The first part of the puzzle to implement concurrency checks is to send the original values of given properties back from the client that you want to compare for concurrency violations before an update operation. In order to minimize data traffic passing between the client and the server, only the original values of the entity's properties that are decorated with the ConcurrencyCheck attribute, the TimeStamp attribute, or the RoundtripOriginal attribute will be sent back to the server when performing an update operation. Therefore, you need to specifically identify these properties to RIA Services so their original values are returned to use in the concurrency check. However, despite providing the framework to identify the fields to use on concurrency checks, RIA Services doesn't actually provide the logic to implement the concurrency checks themselves. Instead, it leaves the task of identifying concurrency violations to the data access layer.

If you are using the Entity Framework as your data access layer (as we are in this book), then you can simply configure the entities in your entity model to perform concurrency checks prior to an update, specifying which of the entity's properties will participate in the comparison check. In your entity model, select one of these properties on the entity, and from the Properties window change its Concurrency Mode property from None to Fixed.

If you need to compare more than one property on the entity for a concurrency violation, then repeat this for each property that should participate in the comparison. Now, prior to any update of that entity, the stored version of the entity will be loaded from the database, and the stored values of the specified properties retrieved will be compared to their values as returned from the client, and a concurrency violation exception will be thrown if any of the values being checked are different.

For example, the Product entity contains a property called ModifiedDate (with a type of DateTime), which we can use to perform concurrency checks. When updating the entity, we want the original value of this property to be sent back to the server along with the updated entity, and if its value has changed in the database since the entity was originally retrieved, then a concurrency exception should be thrown. To specify that this property should be used for the concurrency check, find the Product entity in your entity model, select the ModifiedDate property, and from the Properties window set its Concurrency Mode property to Fixed.

Assuming you have implemented functionality in your Silverlight application to retrieve and update Product entities, you can test it using two copies of your Silverlight application that are open at the same time in different browser windows. Retrieve a given Product entity from the server in one instance of the application, and retrieve exactly the same entity in the other. Make a change to the entity in one instance, and send it to the server to update the database with the change. Now make a change to the entity in the other instance and send the update to the server. Because you updated the entity in the first instance, the ModifiedDate property of that entity on the server will have changed from its original value that is being sent through with the update in the second instance. Therefore, when the Entity Framework compares these values and finds that they are different, it will throw a concurrency exception.

In this sort of scenario your domain service will inherit from LinqToEntitiesDomainService, which provides the ResolveConflicts method that you can override, which will be called when a concurrency conflict has occurred, and enable you to handle it using some custom logic on the server side if you wish. This method returns a Boolean value—if it returns false, then the client will simply be notified of the conflicts. If your method returns true, then the changeset will be resubmitted to the database once again (however, this will happen only once).

As mentioned earlier, a little more work is required if you are exposing presentation model objects to the client instead of entities. In this case you will need to specify which properties should have their original values sent back to the server when updating an object, and then handle the concurrency check logic yourself when updating the database.

The first step will be to decorate the properties on the presentation model object that will participate in the concurrency check (generally in the object's metadata class) with one of the attributes that ensure that the original value of that property will be sent back with any update of the object to the server (i.e., ConcurrencyCheck, TimeStamp, or RoundtripOriginal). For example:

[ConcurrencyCheck]
public DateTime ModifiedDate { get; set; }

You then need to compare the original value of this property with its stored value in the update operation of the domain service. However, you will find that only the updated version of the entity is passed into the operation as a parameter, whereas you also need the original version of this entity for your comparison. You can retrieve the original version of the object using the GetOriginal method of the ChangeSet object. Note that on this "original" object, only the properties specified to be round-tripped will have values.

ProductPM originalProduct = ChangeSet.GetOriginal<ProductPM>(currentProduct);

The next step depends on how you have implemented your data access layer. If your data access layer already performs concurrency checks, then no additional work is required. Otherwise, your update domain operation will need to manually retrieve the stored version of the entity from the database and compare the values of the properties between this and the original version to identify a concurrency violation. If one is found and you want to notify the client, you will need to get the ChangeSetEntry object for the object being updated, and assign values to its ConflictMembers, StoreEntity, and IsDeleteConflict properties. For example:

ProductPM originalProduct = ChangeSet.GetOriginal<ProductPM>(currentProduct);
ProductPM storedProduct = GetProduct(currentProduct.ProductID);

if (storedProduct.ModifiedDate != originalProduct.ModifiedDate)

{
    ChangeSetEntry entry =
        ChangeSet.ChangeSetEntries.Single(p => p.Entity == currentProduct);

    List<string> conflicts = new List<string>();
    conflicts.Add("ModifiedDate");
    entry.ConflictMembers = conflicts;

    entry.IsDeleteConflict = false;
    entry.StoreEntity = storedProduct;
}
else
{
    // Save ProductPM...
}

Handling concurrency violations on the client side will be covered in Chapter 7.

As previously mentioned, RIA Services is built on top of WCF. You will no doubt be familiar with WCF if you have ever written an application that consumes data from a server. In essence, WCF is a unified communication layer that implements a single programming model that can target different communication technologies. It enables you to write the messaging features for an application in a technology-agnostic manner, with the actual technology to be used (referred to as bindings) specified through configuration files. In other words, you can write the communication functionality for your application without worrying about what technology it will use and how that communication will take place, and without tying your application to a specific messaging technology. This is achieved by WCF providing a common model for you to write services against, which it can then map to the configured messaging technology. This model is broken into three components—the service's address, its bindings, and its contract, with a clear separation maintained between each. You define the contract (i.e., the functionality to be exposed by your service), and then you can configure the address and the bindings that the service supports to form a service endpoint.

WCF Data Services (or Data Services for short) is another data-centric communication technology built on the WCF stack that exposes data to clients as JSON- or ATOM-serialized RESTful resources using the OData protocol. The OData protocol specifies how a client can query, navigate, and update data exposed by a service. Using this protocol, the client can communicate with the service in a RESTful manner by retrieving data using a standard HTTP GET call (using specially constructed URIs), and sending updates to the server using a standard HTTP POST call.

Despite being considerably more work (since you will have to parse the results yourself), another means of communicating with a server is through the use of standard HTTP requests. For example, you may wish to download an XML file from the server, or even consume RESTful services (aka WebHTTP services). You can also use this method to download files from a server (such as images).

private void StartDownload(string url)
{
    WebClient client = new WebClient();
    client.DownloadStringCompleted += client_DownloadStringCompleted;
    client.DownloadStringAsync(new Uri(url));
}

private void client_DownloadStringCompleted(object sender,
                                            DownloadStringCompletedEventArgs e)
{
    string result = e.Result;
    // Do something with the result
}

WebRequest.RegisterPrefix("http://", WebRequestCreator.ClientHttp);

Sockets enable you to communicate bidirectionally with the server (i.e., the client can send messages to the server, and the server can send messages to the client). This is particularly useful when you want the server to send the clients notifications, or if you are writing a chat client, for example. Silverlight supports socket communication (with classes in the System.Net.Sockets namespace for support. For scenarios where you want to broadcast messages to all clients, IP multicasting is also supported.

As discussed earlier, you are restricted to only using ports 4502 to 4534 unless you are running in OOB mode with elevated privileges. Sockets are best used in intranet applications (rather than public-facing applications), as the ports will possibly be blocked behind a firewall. In this case you may be better off using a WCF service using the pollingDuplexHttpBinding binding to implement bidirectional duplex communication with the server.