Why does Microsoft assume that we want to combine our business, data access, service, and web layers together in a single web project? Without sounding too much like a rant here, take a look at almost ALL of Brad Abrams (former Microsoft Architect for WCF RIA Services and Entity Framework) posted examples of how to use the Entity Framework with RIA Services. They all have the Entities, RIA Services, and pretty much all of the other data logic included in the Web Application project.

Obviously, this does not promote re-use of the single most shared component in most enterprise companies systems, the Data Access Layer (DAL). Not many are going to need to reuse the domain services generated for a project because they are going to have a lot of hard-coded logic that is specific to an application (maybe that is debatable because you could design this for a lot of reuse) but many applications access the same database and having to rebuild the same model, maintain it in multiple projects, and any customizations and validation you add very problematic. Since the inclusion of the great visual designer tools in the first version of ASP.NET, Microsoft has been on this path of tightly coupled, small project coding that makes reusing something as a component/assembly/DLL in another project difficult if not impossible.

Silverlight Issues with Coupled Components

Unfortunately, this trend is continuing with the amazing Silverlight/RIA Services/Entity Framework stack which is really awesome. I can’t say enough great things about it but I really have to take issue with the assumption about tight coupling. Yes, if your project is small and you have a small database and you are only one of a few developers and work on a single product (BTW: This is probably the majority of software projects so that is why they have focused on this), then this solution works great. If you have multiple products that access the same database, have to create API/Web service access to your systems, have to share code with 100’s of developers, or need to reuse components and libraries across lots of projects, then you will be left scratching your head on examples. The same thing for how Microsoft is showing examples for Silverlight applications.

So here we have put together a tutorial for how to create a project with your DAL, RIA Services, Web project, and Silverlight components all in separate assemblies. These assemblies are reusable and can be shared across applications. This also has the nice benefit of organizing the code and keeping every assembly focused on a single capability.

Project Structure

I want to say a few things about project structure and naming with Visual Studio 2010. Here is a screenshot of the project structure:

Although not specific to implementation, we use a naming convention where we preface project/namespaces for Silverlight assemblies and web applications with “client” and assemblies and web projects that are specific to be run on the server are prefaced with “server”. I know, I know, there are already icons for these types of projects to help differentiate them but the icons are so small and look so similar to it hard to track. Also, it is nice to have a namespace that tells you in the code where a particular object or component maps to.

Description of Project Structure

The projects listed here are as follows:

EntityComponentTest.Client.Data – This is a stub for the data access layer on the Silverlight side. This assembly interacts directly with the server’s Entity Framework DAL layer.

EntityComponentTest.Client.WebApp – This is the Silverlight web application where the XAP is compiled into. This contains App.xaml and MainPage.xaml.

EntityComponentTest.Server.Data – The DAL for the application. This is where the Entity .edmx files are located.

EntityComponentTest.Server.Service – This is where the WCF RIA Services which use the Entity Framework objects to pass data to and from the database to the Silverlight client.

EntityComponentTest.Server.Web – The web project where the pages that host the Silverlight XAP are hosted.

Creating the Projects

Here are the basic steps to get this all working. Once you’ve created your solution to hold these projects, first add the server-side projects.

NOTE: To get this to work right, you need to make sure all the tools for Silverlight including the RIA services toolkit are installed on your development machine. You can get the tools here: http://www.silverlight.net/getstarted/

Create a new ASP.NET web project and name it according to your naming standard. This will be where the Silverlight XAP is hosted. (EntityComponentTest.Server.Web)

Create a new Class Library for the DAL layer. This is where your Entity Model (edmx) will be placed. (EntityComponentTest.Server.Data)

Create a new Class Library for the WCF Services. This is where your WCF RIA services will be placed. (EntityComponentTest.Server.Service)

Create a new Silverlight Class Library for the DAL stub on the client side. Make sure this is a Silverlight assembly. (EntityComponentTest.Client.Data)

Create a new Silverlight Application. This is the main app that will be packaged in your XAP for the logic of your Silverlight application. NOTE: When you do this, the system will probably ask you if you want to associate this project with your web application. Say yes, and let it create a page for you and hook it all up. (If you forget to say yes here, it is easy in the web project properties to set the Silverlight application later).

Setting References

Set a reference from the EntityComponentTest.Server.Web project to the EntityComponentTest.Server.Service project.

Set a reference from the EntityComponentTest.Server.Service project to the EntityComponentTest.Server.Data project.

Set a reference from the EntityComponentTest.Client.WebApp project to the EntityComponentTest.Client.Data project.

Configure Settings to get WCF RIA Services to talk to Silverlight

A few settings need to be configured in order to get the WCF RIA Services to show up in the Silverlight application. Right click the EntityComponentTest.Client.Data project and choose “Properties” from the context menu. Set the properties on the Silverlight tab for the WCF RIA Services Link to the EntityComponentTest.Server.Web project similar to this screenshot.

Now edit the Web.Config in the EntityComponentTest.Server.Web project so that the services will be able to be served by the web project (basically handles custom pathing for service URL’s and importing the System.Data.Entity assembly. Add this element to the Assemblies section:

<add assembly="System.Data.Entity, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />

Add this element to the httpModules section:

<add name="DomainServiceModule" type="System.ServiceModel.DomainServices.Hosting.DomainServiceHttpModule, System.ServiceModel.DomainServices.Hosting, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />

Add this element to the System.ServiceModel section:

<serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true" />

Your web.config will look similar to this:

Setting up the Entity Model

Now in the EntityComponentTest.Server.Data project add an ADO.NET Entity Data Model (edmx) file to store your data model.

I have created a simple database table to illustrate the process called “Customer”. Here is a view of what the table schema looks like in SQL Server.

Now connect your entity model to your database and add this customer table to your edmx model. Your model should look like this when you are done.

Setting up the WCF RIA Service

Now we can create a WCF RIA Service to access this table to do selects, inserts, updates, and deletes from the Silverlight client. But MS has made this harder than it should be to get it to work in your loosely coupled project. You have to do a little trickery to get this to work.

NOTE: The reason for this is that the “service.metatadata.cs” files that are auto-generated when the service is added for its Entity model(s) MUST be in the same assembly as the Entity Model (edmx) itself. This is a hard and fast rule. But we don’t want our services (web access layer) in the same assembly as our data model (what if we want to use our DAL layer somewhere else and don’t want to expose it through RIA services?).

To get around this, we first add a Domain Service Class to our EntityComponentTest.Server.Data project first.

This will create the metadata.cs file(s) in the correct place and set your services up right. Then move the newly created “service class” (DevToolShedService.cs in this example) to the EntityComponentTest.Server.Service. Then to get this to fully work in your service assembly, you need to change the namespace for both the DevToolShedService.cs and DevToolShedService.metadata.cs classes to point to the EntityComponentTest.Server.Service. So your Service class should look like this at the top when you are done.

Testing the Application and WCF RIA Services

To test the application, go the MainPage.xaml in the EntityComponentTest.Client.WebApp and add a DataGrid so we can show the list of Customers from our Customer table. You XAML should look something like this:

<UserControl x:Class="EntityComponentTest.Client.WebApp.MainPage"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    xmlns:sdk="http://schemas.microsoft.com/winfx/2006/xaml/presentation/sdk"
    mc:Ignorable="d"
    d:DesignHeight="300" d:DesignWidth="400">
    <Grid x:Name="LayoutRoot" Background="White">
        <sdk:DataGrid Name="dgTest" AutoGenerateColumns="True" Height="500" Width="500" HorizontalAlignment="Left" VerticalAlignment="Top" />
    </Grid>
</UserControl>

Now in the MainPage.xaml.cs code behind, we can bind our Customer data to the grid with code similar to this:

namespace EntityComponentTest.Client.WebApp
{
    public partial class MainPage : UserControl
    {
        public MainPage()
        {
            InitializeComponent();

            this.Loaded += new RoutedEventHandler(MainPage_Loaded);
        }

        void MainPage_Loaded(object sender, RoutedEventArgs e)
        {
            // create a context to the WCF RIA service and call the RIA service method
            // to get the list of all customers.
            var context = new Server.Service.DevToolShedContext();
            dgTest.ItemsSource = context.Customers;
            context.Load(context.GetCustomersQuery());
        }

    }
}

Now run your project and you should see a list of customer data from your Customer table working and everything is decoupled (as much as we can in Silverlight) and this makes it easy to re-use your data access layer in other projects without having to bring all your exposed RIA services with it.

You can download the solution and project files for this project here:

EntityComponentTest.zip