EntitySpaces and Silverlight Demo - .NET Studio 2008

Introduction

I was asked to see how easy it would be to get EntitySpaces objects to work inside Silverlight, and to demonstrate my findings. This was a curiously interesting notion, since many have pondered whether Silverlight is a valuable runtime environment for LOB (line-of-business) applications. There are a number of reasons why Silverlight, at least in its Version2 flavor, would be very ideal for building client/server applications:

· Silverlight 2 comes with pre-built user controls ideal for business environments, such as the basic Textbox and more advanced data grid with editable cells

· Silverlight 2's user controls support two-way data binding, so that synchronization can be performed easily in either direction

· Silverlight 2's runtime is fast and fluid, using retained graphics vector-based rendering rather than redraw-at-invalidate "lazy" rendering. This results in a very responsive, clean, and professional user experience.

· XAML takes lessons learned with ASP.NET with the separation of design from programming. Properly implemented, a Silverlight application can be completely re-skinned, with its layout completely reorganized, without touching any of the user interface programming code.

· Silverlight 2 ships with built-in support for the language of your choice of: C#, VB.NET, IronRuby, IronPython, or JScript.NET. The .NET Framework itself inside of Silverlight is stripped down, but the core CLR is complete, and the target deployment environment does NOT need the .NET Framework installed with it.

· Silverlight 2 runs not only on the Windows platform and on Internet Explorer, but it also runs happily on the Macintosh and in other browsers such as Firefox and Safari. This means that Silverlight is not just Microsoft's answer to Flash for its vector graphics, it's also Microsoft's decade-long-awaited answer to Java applets, "Write once, run anywhere." An investment in Silverlight on Windows is automatically a free, bonus investment in the Mac and Firefox runtime environments.

· Silverlight 2 is also capable of communicating at runtime with web services over HTTP, making synchronization a natural programming experience without "hacking".

So here I began. My first thought was to take the EntitySpaces generated objects and put them in a shared library, then reference them in my Silverlight application. This turned out not to work as I hoped, for a few important reasons worth mentioning:

· Silverlight 2 can only reference assemblies (DLLs) that had been compiled against Silverlight's custom CLR. It cannot reference assemblies that were compiled against the normal .NET Framework (or against Mono).This is actually an opportunity for EntitySpaces, at least in its current form, because ES is built around code generation, so theoretically you could get the generated code to target Silverlight. Or so I thought, until I found...

· Silverlight 2 only "speaks" HTTP. It doesn't "speak" T-SQL, so you cannot use an ADO.NET connection, for example. There is no System.Data namespace, no ADO.NET support. While this seemed bizarre and even annoying at first, eventually I began to understand, besides for obvious security reasons, why System.Data was not present in Silverlight 2 in the current beta form: CRUD is CRUD, it doesn't matter if it's happening over ADO.NET on a SQL connection or over HTTP, as long as the job gets done.

Now I was beginning to procrastinate, because I made too many dumb assumptions. "So I guess I have to use System.Net.WebClient", I thought, "to make a manual connection to a web server, invoke a REST query I have to manually implement on the server, and then manually bring it back, parse it out, and in the end enjoy no benefit to using EntitySpaces at all?" When I finally sat down and researched what I needed to do, my jaw dropped. It’s nothing like that. In fact, it's almost silly how simple this is. The answer to the problem of the need for easy business object data synchronization lies in a wonderfully consistent new approach provisioned by Microsoft called WCF, or Windows Communications Foundation, now implemented at a basic level in Silverlight.

WCF support on Silverlight is limited to basicHttpBinding (SOAP 1.1). But that binding should suffice for most business scenarios.

The power of WCF is actually somewhat less about the underlying technology than it is about the code generation tools built into Visual Studio for building out the necessary client proxy stubs from defined interfaces at design-time. EntitySpaces' built-in WCF took me there 75% of the way, but the Silverlight SDK closed the gap very quickly by allowing me to reference my WCF service in just a couple clicks.

There was no coding of System.Net.WebClient. No manual conversion of XML to C# objects. Just beautiful EntitySpaces proxy stubs that enabled me to gather rich business object data from a server and perform quick and easy data binding against Silverlight with minimal effort.

So in this first part, I'll describe the first "baby step" of getting Silverlight to interoperate with a WCF service in order to pass valuable EntitySpaces objects into Silverlight with very little effort. Following that, in the next part I'll describe a simple scenario of fetching filtered data based on a WCF callback parameter that then takes advantage of EntitySpaces query filtering on the server, again with only a few more lines of code. Finally, if I have time, I'll continue to research and then demonstrate how to take advantage of the new client-side query support that is already available in ES 2008's latest build, adding even more flexibility to the programming user experience.

Run the Demo Here ==> http://developer.entityspaces.net/ES2008/Demos/Silverlight/PartOne

Download the Source Here ==> http://www.developer.entityspaces.net/downloads/EntitySpacesSilverlightDemo.zip

Setup

These are the prerequisites you need to walk through this demo:

· Visual Studio 2008

· EntitySpaces 2007

· Microsoft Silverlight Tools Beta 1 for Visual Studio 2008

· Northwind database

Figure 1 - Download the Silverlight tools for Visual Studio

Setting Up the Project and Generating Northwind Business Objects

If you’re not already familiar with EntitySpaces, we need to walk through some initial code generation so that we have some business objects to begin with.

Since nearly everything we’re doing is going to be done inside of Visual Studio, let’s start off by creating a new solution.

Figure 2 - Start up Visual Studio and start by creating a new Project

Figure 3 - Create a Silverlight Application using .NET Framework 3.5

Figure 4 - When you create a Silverlight Application, Visual Studio prompts you to ask whether you want to create a new web to the solution or if you just want a local HTML test page. Choose to add a new Web.

In my opinion, the data objects that get passed around in an application should exist in their own class library and then referenced into the application that uses them.

Figure 5 - Add a new project to the solution ...

Figure 6 - .. and choose Class Library as the project type. You can delete the resulting Class1 file.

I’m going to use MyGeneration 1.3 for this demonstration. After preparing Northwind for SQL Server, I can then fire up MyGeneration.

Figure 7 - Open the template browser

Figure 8 - Expand EntitySpaces, then C#, then right-click Generated Classes Master (C#), and choose Execute.

Figure 9 - I have a Visual Studio class library project set up, waiting for new code to be added to the physical directory so that I can add the files to the project after they are generated.

Figure 10 - I'd like to give the Namespace a similar name as the database: NorthwindData

Figure 11 - You can pick and choose your tables -- we'll use Products and Categories -- but might as well select them all.

Figure 12 - On the third tab, we want to enable the WCF proxies, as highlighted in the image.

Figure 13 - Click the OK button at the bottom to generate the objects

Figure 14 - After a moment, you may receive a confirmation message. If not, no worries, as long as your error log window isn’t filled up.

Now I can close MyGeneration and go back to Visual Studio.

My NorthwindData project doesn’t have anything in it yet, let’s add the newly generated files.

Figure 15 - Click the "Show All Files" toolbar button in the Solution Explorer window.

Figure 16 - Now we can see our generated files. Right-click on the folder and choose "Include In Project".

Before we can call this class library “ready”, we need to remember to reference the EntitySpaces dependency assemblies.

Figure 17 - You need EntitySpaces.Core and EntitySpaces.Interfaces ..

Figure 18 - .. as well as System.Runtime.Serialization and System.ServiceModel for WCF proxy support.

Finally, we should also add the same references to the Silverlight_Web project, as well as EntitySpaces.Loader, EntitySpaces.LoaderMT, EntitySpaces.SqlClientProvider, EntitySpaces.Web, and EntitySpaces.Web.Design.

You will also need to add updates to your web.config for EntitySpaces to be able to read from (and later write to) the Northwind database. Here’s what I have ..

allowLocation="true" allowDefinition="Everywhere" restartOnExternalChanges="true"/>

...

...

providerClass="DataProvider"
connectionString="Data Source=.\SQLEXPRESS;AttachDbFilename=|DataDirectory|\NORTHWND.MDF;Integrated Security=True;User Instance=True" databaseVersion="2005"/>





...

Discovering the Silverlight Tools

Before you got this far, you should have discovered that when you added the Silverlight Application, the Page.xaml file loaded right up to be edited. It might have looked like this:

Figure 19 - The XAML Editor view for a Silverlight Application

This is a design canvas for a Silverlight application layout. Silverlight works like ASP.NET in that the design and the programming code are isolated from each other. There is a “code-behind” file, or a similar principle, just as with an .aspx file.

In the design (XAML) editor, there are two views on a split pane.

One view is the XAML text editor. Think of it as an HTML editor in a split pane view, such as in Microsoft Expression Web or in Dreamweaver. The only big difference here is that XAML isn’t HTML, obviously, and in fact XAML is much stricter and less forgiving of errors than HTML ever was. Even so, its power becomes evident when elements can be added to a view with minimal markup.

Figure 20 - The XAML text editor pane.

The other view is the Design view. Currently (at the time of this demo, the Silverlight Tools was only in Beta 1), this only works as a preview in Visual Studio. You can drag items from the toolbar to your layout, but only into the XAML text editor, not to the Design view. This isn’t the case if you have access to Blend 2.5, which at the time of this demo is currently in public Alpha (Technology Preview) and was not used for this demo at all. The design view does have some advantages, though. It provides a quick visual preview of the XAML text, and if you need to nitpick you can zoom in or out.

Figure 21 - The Design pane.

So let’s start adding some XAML and some logic to get, say, a data grid populated with the entire contents of the Northwind “Products” table, as provided by the EntitySpaces business objects we generated earlier.

Personally I don’t care for fixed dimensions before we even begin let’s just delete the Width and Height attributes on the XML node. This will make Silverlight fill the screen or else collapse to the largest object.

Next I want to add a data grid.

Figure 22 - Drag a DataGrid control to the content.

I’ll add the attribute x:Name=”ESGrid”, which is the ID of the control on the page. The attribute AutogenerateColumns=”True” does what it suggests; when data is bound to the grid, the columns are automatically generated. (Without this setting, the grid would come up blank because I am not providing layout information for the columns.)

x:Name="ESGrid" AutoGenerateColumns="True">

The next thing we should do is insert a “Please Wait” text block so that as we download the Products list. This is just for effect so that the user isn’t staring at a blank DataGrid or a blank screen before the data shows up. To make this effective, we should also hide the DataGrid until the data is ready.

Visibility="Collapsed" />

Now all our Silverlight app wants is some data. But before we can populate the DataGrid, we have to expose the data. So now we turn to our Silverlight_Web project.

Exposing the Data via A WCF Service

Open up the Property Pages for the Web project.

The first thing that should come up is a list of References. Add a reference to the Northwind project

With Northwind added, we can now add a WCF service. Right-click on the Silverlight_Web project again and choose Add New Item…

.. and then choose WCF Service. We’ll name it “Northwind.svc”.

This generates four things:

• An interface file defining the interface INorthwind
  
• A Service (Northwind.svc) file that only acts as a stub for the code-behind C# file
  
• A service implementation file (Northwind.svc.cs or App_Code/Northwind.cs) where the service code is actually going to be written, and finally
  
• A set of entries in web.config that define
  
  
  • Your site’s serviceModel configuration settings such as the EndPoint configuration
    
  • Bindings to the Northwind service

In the Northwind service implementation, you’ll see a bogus DoWork method stub defined and exposed, like so:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Runtime.Serialization;
using System.ServiceModel;
using System.Text;

// NOTE: If you change the class name "Northwind" here, you must also update the reference to
// "Northwind" in Web.config.

public class Northwind : INorthwind
{
public void DoWork()
{

}
}

You can toss this out but before you do you need to go and modify INorthwind.

Notice that INorthwind attributes itself with the ServiceContractAttribute. This identifies the interface as a WCF service interface definition. Exposed methods are attributed with OperationContractAttribute.

[ServiceContract]
public interface INorthwind
{
[OperationContract]
void DoWork();
}

Before we can see the Northwind project’s stuff in Intellisense, we need to build both it and the Silverlight_Web project. Right-click on the Silverlight_Web project, choose Build Web Site, and the Northwind project will build first because it is a dependency. (This is also a good time to check for errors.)

Now let’s add some code.

In INorthwind, replace “DoWork()” with “GetProducts()”, and change “void” to “NorthwindData.ProductsCollectionProxyStub”. Then go back to the service implementation file and replace “DoWork()” with “GetProducts()” again and “void” to “NorthwindData.ProductsCollectionProxyStub”.

Next, we can give the method stub some functionality.

public NorthwindData.ProductsCollectionProxyStub GetProducts()
{
NorthwindData.ProductsCollection products = new NorthwindData.ProductsCollection();
products.LoadAll();

NorthwindData.ProductsCollectionProxyStub proxy = new NorthwindData.ProductsCollectionProxyStub(products);
return proxy;
}

This will fetch all products, wrap them in a WCF-ready proxy, and spit back the proxy.

Now let’s make sure that our WCF service is functioning. Hit the Debug button in Visual Studio (while the Silverlight_Web project is selected) and when the web page comes up, navigate to Northwind.svc. You may get a prompt asking if you want to enable debugging, just say yes.

If you can see the “Northwind Service” page, indicating “You have created a service,” you’re almost ready to start binding your service to Silverlight.

Stop the debugger before continuing.

Initializing EntitySpaces

Before this service will successfully work with EntitySpaces at runtime, the EntitySpaces runtime needs to be initialized to point to a database.

Right-click on the Silverlight_Web project node in Solution Explorer and choose “Add New Item...”, then select “Global Application Class” (name it the default, Global.asax). When it opens up, add the following code in Application_Start():

protected void Application_Start(object sender, EventArgs e)
{
EntitySpaces.Interfaces.esProviderFactory.Factory = new EntitySpaces.LoaderMT.esDataProviderFactory();
}

Binding the WCF Service to Silverlight

Silverlight “speaks” WCF, but only using basicHttpBinding (SOAP 1.1). We need to update the endpoint configuration on the service so that it uses basicHttpBinding rather than the default wsHttpBinding.

Open web.config in Silverlight_Web and change wsHttpBinding to basicHttpBinding.

...




...

We also need to create a temporary lock on the port that our development web server (Cassini) is using. When Web projects are created within Visual Studio, a small web server loads up in the background, with a visible icon in the Windows Notification Area (or “system tray”), and the port that it uses is random. If we lock it, though, we can force Silverlight’s WCF bindings to always point to the correct web address when it calls back to the web server. This is only for debugging purposes; when deploying to production, a URL will be used literally, on port 80, as with http://www.mydomain.com/myService

To lock the web server port so that we can get a fixed reference on Silverlight, click on the Silverlight_Web project node in the Solution Explorer tree and disable the “Use dynamic ports” option.

Now it’s time to bind your WCF service to Silverlight. Right-click on the Silverlight project node in the Solution Explorer and choose “Add Service Reference ...”

Then select “Discover >” and choose “Services in Solution”. The Silverlight_Web project is displayed. Expand it until you see the Northwind service, then expand that until you see the INorthwind service contract. Select the INorthwind service contract, and set the Namespace to “NorthwindClient”.

Once you click on “OK”, the required assemblies for WCF support, all pre-compiled against the Silverlight runtime, are brought into Silverlight automatically.

Great, I have my bindings. Now it’s time to populate my grid.

If you expand the Page.xaml node in the Solution Explorer, you should see the Page’s “code-behind”-ish file. Open that up and see what’s inside.

// using stuff ;
namespace EntitySpacesSilverlightDemo_Silverlight
{
public partial class Page : UserControl
{
public Page()
{
InitializeComponent();
}
}
}

So we already have a constructor here where we can fire off an invocation of the WCF service. Note: All System.Net.WebClient and WCF client calls are asynchronous, so you must plan for this ahead of time whenever programming callbacks with Silverlight.

After adding “using NorthwindClient;” to the top of the file, here’s my code for within the “class Page” block:

NorthwindClient.NorthwindClient ESNorthwind;

public Page()
{
InitializeComponent();
ESNorthwind = new NorthwindClient.NorthwindClient();
ESNorthwind.GetProductsCompleted += new EventHandler(NorthwindClient_GetProductsCompleted);
LoadAllProducts();
}

private void LoadAllProducts()
{
WaitText.Visibility = Visibility.Visible;
ESNorthwind.GetProductsAsync();
}

void NorthwindClient_GetProductsCompleted(object sender, NorthwindClient.GetProductsCompletedEventArgs e)
{
WaitText.Visibility = Visibility.Collapsed;
NorthwindClient.ProductsCollection pc = e.Result;
ESGrid.ItemsSource = pc.Collection;
ESGrid.Visibility = Visibility.Visible;
}

Hit F5 and run, and you should see something like this:

This is what we were designing for. We have a data-bound DataGrid, where the data derives from the same EntitySpaces business objects I perhaps already invested in elsewhere on my site or in my application, and despite a learning curve for basic configuration for WCF interop, there was actually very little code that was written by hand.

Deployment to IIS

We’re not quite done yet. Now we have to look at deployment to a production server.

Silverlight’s binding to the services is hard-coded to the URL http://localhost:11434/Northwind.svc. Silverlight is then compiled and bundled directly into the web project that hosts the WCF service. We now have a chicken-or-egg situation; both projects depend on the other. Further, EntitySpaces is hosting this demo on a shared web host that uses IIS 7 which enables WCF services natively, but WCF on IIS 7 doesn’t support HTTP endpoints through web.config without a custom service factory.

Here’s a run-down on how we got this running at: http://developer.entityspaces.net/ES2008/Demos/Silverlight/PartOne/

1. Upload the web project files to the web server via FTP and make sure that the directory paths correctly reflect the desired URLs.
   
2. In Visual Studio, with the Solution still open, choose File -> Add -> Existing Web Site..., then select FTP on the left and fill out the necessary FTP information (hostname, username, password, directory).
   Be sure to enter the exact FTP directory path to the root of the web project.
   
3. We now have two copies of the same web project loaded in our solution, the local copy and the FTP-based copy. Now we need to make some configuration changes in the FTP-based copy of the project in our solution.
   • Re-link the Silverlight project. Right-click on the Project node in the Solution Explorer, choose Properties Pages, and select Silverlight Links. (If anything there, remove it now so it is empty.) Click “Add...”, ensure that your Silverlight project is available in the drop-down list for “Project to link”, and keep the Destination folder set to “/”. Click Add and then click OK. You may get some warnings that the file(s) already exist, go ahead and choose to overwrite.
     
   • Restore the database connection. In web.config, change the connection string at configuration/EntitySpaces/connectionInfo/connections to point to a working instance of Northwind on SQL Server on the web host.
     
   • Add a Northwind service factory to the project. Open App_Code/Northwind.cs and make the following changes:

     // append to the "using" declarations at the top
     using System.ServiceModel.Activation;
     using System.Configuration;
     
     // append inside of namespace but before or after the Northwind class block
     public class NorthwindServiceHostFactory : ServiceHostFactory
     {
     protected override ServiceHost CreateServiceHost(Type serviceType, Uri[] baseAddresses)
     {
     // Specify the exact URL of your web service
     Uri webServiceAddress = new Uri(ConfigurationManager.AppSettings["ServiceUri_Northwind"]);
     NorthwindServiceHost webServiceHost = new NorthwindServiceHost(serviceType, webServiceAddress);
     return webServiceHost;
     }
     }
     
     public class NorthwindServiceHost : ServiceHost
     {
     public NorthwindServiceHost(Type serviceType, params Uri[] baseAddresses)
     : base(serviceType, baseAddresses)
     { }
     
     protected override void ApplyConfiguration()
     {
     base.ApplyConfiguration();
     }
     }

   • Find the node of web.config (which might be collapsed as , just change it to ) and add the following setting inside of it:
     
     
     
   • In web.config, under configuration/system.serviceModel/behaviors/serviceBehaviors, add:

     
     
     

   • Finally, under configuration/system.serviceModel/services, change

     
     
     .. to ..
     
     
     
     .. and although I don’t think it’s used anyway with our factory, you might want to go ahead and change the localhost entry down in there to yourhost.com.
     

4. Build the solution. If build succeeds, ...
   
5. In the Silverlight project, expand the Service References node in the Solution Explorer and remove the NorthwindClient node by right-clicking it and choosing Delete. Then right-click on Service References and choose Add Service Reference. Click on Discover and choose Services in Solution. Select the FTP-based project. You may be asked to refine the URL, you will need to modify the default value to correctly reflect the accurate URL path to the Northwind.svc file on the live server.

If you receive an error, open up a web browser and navigate directly to the URL of the Northwind.svc file. If it fails to show up, try to use the error message (Google is your friend) to drill down the problem. It may relate to something overlooked in the steps I described.

6. Now right-click on the Silverlight project node in the Solution Explorer and build the project again.
   
7. Finally, right-click on the web project node in the Solution Explorer and build the project again. This will pull the revised compiled Silverlight project into the hosted site.
   

If you made it this far, all the hard stuff is over!! From here on out, it’s easy, blissful C# coding with EntitySpaces and a few XAML tweaks, no more configuration hassles.

In Part 2 of this tutorial / demo, I’ll make the app a little bit more interactive, adding filters and the ability to make a few changes to the data. (It will be comparatively short compared to this part.) But now that you know how to link up ES objects to Silverlight over WCF, have fun and be safe!!