Introduction

If you have not, please see the associated article: POCO Entities Through RIA Service, as this article is the companion to using plain old class objects (POCO) entities through Rich Internet Application (RIA) Services. You could use this example to host anything via the Open Data Protocol (OData), really - not just POCO entities. For this example, you must have the following installed:

Background

A problem arises with using POCOs, which is that you might need to include relationships through LINQ or other data contexts. Microsoft wrote an article on sharing entities using the Include statement, but it does not work with POCOs because they should be context unaware. Also, as is often the case, you might want to join two .edmx files, or provide some highly customized business relationship between your entities, or you might even want to do user access checks before providing data, or you might want to implement the Model View View Model (MVVM) pattern, like this example.

Creating a Domain Service Factory

My WCF RIA Services Class Library project from the previous article (see Introduction) is called EntRiaServices, and it has a sub-project called EntRiaServices.Web. This is where we are going to be creating our Domain Service Classes along with our Domain Service Factory. These are two classes, so right-click on the EntRiaServices.Web sub-project and select Add, New Item, Class.

A Domain Service Factory (DomainServiceFactory.cs) is a class that will produce your available domain services for RIA Services to access:

The second class (AccessableDomainService.cs), or however many you want, is your accessible Domain Service(s). All of your Domain Services should expose subroutines marked with [Query], [Update], [Insert], and [Delete] attributes:

As you can see from these two classes, the factory overrides the CreateInstance of the particular class and passes in the data context. You could pass in anything at this point, including relationship objects. Another thing you could do is if all of your Domain Services for a particular POCO have the same interface, then you could use polymorphism while associating your Silverlight .xaml with a "UI approved" Domain Service from that set.

Connecting Silverlight to Your Domain Service Factory

My SilverLight Application project from the previous article (see Introduction) is called BusinessApplication1 or BusinessApp. I had to drag a Global.asax in from another project, but if you know how to create one, go for it. The domain service factory can be changed from anywhere in your code, but I like it here:

Next, you are going to update your .XAML file to include a button. If you were following the previous article, you should already have data on your .xaml and the riaControls:DomainDataSource.DomainContext reference setup. The data context in my example is named zipDomainDataSource. I have a demo Save button called Button1. Here is a quick test for the code-behind to perform an update; you will need to press F5 after entering this into your .xaml.cs for your button:

However, it is my preference to reference the View Model directly from the .xaml file because then we can see the object in our data sources. All you have to do is create a reference to your namespace in the page definition: xmlns:myApp="clr-namespace:BusinessApp". Then just reference that resource:

Conclusion

As you can see, having a domain service factory adds a tremendous amount of flexibility to how domain services are provided, and keeps our POCO DLLs context unaware. Concluding this article, the attached solution demonstrates a Silverlight 4 solution using the Model View View Model (MVVM) pattern and POCO entities. I hope this helps all of you C# business application developers out there, because this technology is still fairly new, and it is hard to find good resources.

Some call them PONOs, or plain old .NET objects, and other people call them plain old c# objects. It would be nice if they were not common language runtime (CLR) specific as that is the point to generating them; however, the MetadataTypeAttribute is required in addition to interface scope formulators that are language specific. Still it would not be too difficult to transfer these plain old class objects to Java or another language. I prefer to call them plain old class objects because it reminds me that they are actionable but should not contain any actions. Plain old CLR objects works too.