Silverlight 4 + RIA Services - Ready for Business: Exposing Data from Entity Framework

To continue our series I wanted to look next at how to expose your data from the server side of your application. 

The interesting data in your business applications come from a wide variety of data sources.  From a SQL Database, from Oracle DB, from Sql Azure, from Sharepoint, from a mainframe and you have likely already chosen a datamodel such as NHibernate, Linq2Sql, Entity Framework, Stored Proc, a service.   The goal of RIA Service in this release is to make it easy to work with data from any (or many) of the sources in a seamless way from a Silverlight application.  This walk through will use Entity Framework accessing the Sql Express database, but the basic concept applies to any data source. 

Add DishView.mdf to BusinessApplication1.Web\App_Data – Of course in a real world example, you’d just have a connection string to an existing database.

Then create an Entity Framework model on top of it. 

As you can see, we have a very simple Entity set.. each Restaurant can have any number of Plates.

Next, we need to write some business logic that controls and shapes how to data is seen by the Silverlight client.  To do that, we add a new DomainService.  A DomainService is simply a special kind of WCF service that makes it MUCH easier to query, update, secure and validate your data.    But if you are a WCF expert and know all the ins-and-outs of configuring a WCF service, you can certainly customize this service in exactly the same way to match your needs.   Of course, in the 90% case we hope you will not need to do that.

Next we are given a chance to pre-populate the DomainService.

In this case, we will expose Plate and Restaurant, but only Plate will be updatable.    We will also generate a metadata class for hanging validation attributes on so that you can regenerate the EF model without losing any customizations.    We get a starter DishViewDomainService class.  I have updated it in lines 8-9 with a bit of business logic.   Let’s walk through each line..

   1:     [EnableClientAccess]

  2:     public class DishViewDomainService : LinqToEntitiesDomainService<DishViewEntities>

  3:     {

  4: 

  5:         public IQueryable<Restaurant> GetRestaurants()

  6:         {

  7:             return this.ObjectContext.Restaurants

  8:                 .Where (r=>r.Region != "NC")

  9:                 .OrderBy(r=>r.ID);

 10:         }

 11: 

Line 1: This attribute marks the DomainService as accessible over http, without it, the service is only callable from in process. This is useful in the ASP.NET WebForms\Dynamic Data scenario. 
Line 2: We drive this class from the LinqToEntitiesDomainService this is a utility class that provides a few helpers for working with EF.    The real work is done by the DomainService base class, this is the class you derive from for POCO and other custom scenarios.
line 5: Notice we are returning a IQueryable of our DAL Restaurant type.  IQuerable is the interface LINQ is built on.  This enables query capablities from the client so you can do things like sorting, paging, filtering from the client and have it compose with your custom business logic and execute on the data tier..  This means no extra data is sucked into the mid-tier or the client, but you don’t have gunk up your business logic to deal with that. 
Line 8-9: we have some  business logic that weeds out any Restaurant in North Carolina and puts a default ordering on the results. You can of course imagine more interesting business logic.