Okay, we finally got it!! We can honestly say getting a grip on Silverlight has been a real learning curve for our team, but it’s going to be a breeze for EntitySpaces customers because we’ve done all the research and laid all of the track. Our first approach was to use strings for everything because we didn’t want to use the “brain dead” proxies created by Visual Studio when you add a service reference to a Silverlight project. Then we figured out how we could force Visual Studio to use our client side proxies when adding a service reference. This is truly awesome. I cannot imagine a better way to write Silverlight applications than with EntitySpaces. What we are about to show you is so easy it will floor you. We will also be making a video on this and making our demo available with a future alpha or beta version. Okay, enough hype, show us already !!

Above, is our Silverlight Solution that contains everything needed to run the entire demo. Notice first, that we have all of the EntitySpaces runtime projects included rather than just references to the dlls (EntitySpace.Core35, etc.). We do this as we develop so we can debug and fix things if need be. Naturally, these project references are not required in your solution. You only need to add the runtime dll references to the project which houses your WCF service, EntitySpaces.SilverlightApplication.Web in this case.

Also notice the first project in the red box, EntitySpaces.Proxies.Silverlight. This is simply a Silverlight class library that we added to our solution. Then we generated our client side proxies into that solution. So now we have our client side proxies housed in a Silverlight class library. We could have just added these to our SilverlightApplication but there is a very important reason we didn’t. More on this later. These are generated via our Client Side Proxy Stub Template.

Next we have the SilverlightApplication project itself. This is the Silverlight application that runs in the browser. It references our EntitySpaces.Proxies.Silverlight class library that houses our client side proxies, and it references the EntitySpaces.DynamicQuery.Silverlight assembly because we want to be able to run full “es” DynamicQueries under Silverlight. Of course this project also contains our Page.xaml.cs file which contains our code that executes everything under Silverlight, we’ll be looking at that in a moment.

Finally, we have our EntitySpaces.SilverlightApplication.Web project which houses our WCF service in a web application. The two important files we’ll be looking at here are the INorthwind.cs file and the Northwind.svc.cs file.

Let’s start with the WCF Service

We have two methods. GetEmployees takes a serialized query in string form (the only time we have to use strings is with a query) and returns the data through our server side proxy class “EmployeesCollectionProxyStub”. Our Save method takes and returns a server side “EmployeesCollectionProxyStub” as well. The server side proxy stubs are generated via the Generated Master template. You indicate that you want them created via the Proxy/Stub tab as shown below. Also, be sure and check the “Serializable Queries” checkbox on the advanced tab.

You can see how simple our WCF Service is in this example. Let’s look at the Northwind.svc.cs file.

First, look at the second method, our SaveEmployees() method. Could this be any easier? Not only do you not have to worry about which rows are added, modified, or deleted, but you can simply call Save, and return the very same collection. All new records, including their identity columns and such, will be returned to the Silverlight application so it can update it’s grid (in our case).

The GetEmployees method is a little more complicated, but not by much. It merely deserializes the string (a serialized proxy query) into a full blown EmployeesQuery, asks the EmployeesCollection to load it, then creates an EmployeesCollectionProxyStub class, passing in the EmployeesCollection, and returns it. Pretty simple really.

The Silverlight Application Logic

Let’s take a look at what our Silverlight Application looks like.

What the demo application does is create an EntitySpaces DynamicQuery when the user clicks on the Search button, calls our WCF service method GetEmployees(), then populates the grid with the data. The user can edit the data in the grid, and then merely click the Save button, which calls the WCF service method SaveEmployees(). Again, pretty simple.

So let’s look at our page.xaml.cs file. (We’ve removed any error handling to make the screen shot smaller.)

Notice in SearchButton_Click we create a EmployeesQueryProxyStub and use it exactly as we do with our full server side DynamicQuery objects, only we cannot load it directly. It must be serialized and sent to the server. In the last line of that method, we call our WCF service method GetEmployees().

In service_GetEmployeesCompleted() we assign e.Result to “employees”, which is our client side EmployeesCollectionProxyStub object, then we bind to employees.Collection, and our grid is populated.

Now, in the save button click event we intentionally set the first rows’ name to “GoogyGaga”, then add an additional Employee just for kicks, and call our WCF service method SaveEmployees(), which returns a refreshed collection, which we again assign to “employees”, and rebind the grid.

That’s it folks. An entire Silverlight application using EntitySpaces, showing both sides of the conversation. EntitiySpaces not only provides the glue between Silverlight and WCF, but it also provides all of the database access as well. All generated in mere seconds from your database schema via our Visual Studio Add in. Does it get any better than this?

Making Visual Studio Use the EntitySpaces Proxies instead of Visual Studio Generated Proxies

This is very cool indeed. We do not want to use Visual Studio generated proxy classes because they do not maintain row state for us (and other things). Our client side proxies maintain what rows are modified, added, and deleted such that you can send the entire collection back to the server and simply call Save() on it and bingo, it’s in the database. Here’s the trick. Remember the EntitySpaces.Proxies.Silverlight class library that houses our client side proxies? Well, there’s a reason we needed to have it housed in it’s own Silverlight class library and that is so we could tell Visual Studio to use it rather than generate proxies for us. Here’s how you do that when adding your Service Reference to the Silverlight application.

This is how we add our reference above. However, the trick to forcing Visual Studio to use our client side proxies is performed by pressing the “Advanced …” button.

Notice here that we tell it to reuse the types in our EntitySpaces.Proxies.Silverlight assembly. This is totally awesome. It’s great that Visual Studio allows us to do this. But even better, we were somewhat ahead of our time. Our client side proxies easily serialize into our server side proxies and vise versa. This is exactly what the DataContractSerializer is all about. It allows you to have different classes on each side of the conversation, and it works wonderfully in EntitySpaces.

Summary

This may seem like a lot to soak in but it really isn’t. We’ll be shipping our Silverlight demo hopefully with our next Alpha. Writing Silverlight applications is so graceful using EntitySpaces. Sure, you’re going to need to learn XAML and other things but all of the plumbing, wiring, and track have been laid for you. EntitySpaces has terrific Silverlight support. Everything you see here in this blog post works in our current alpha version. It’s late and we need to get some sleep, we are really jazzed about this and if anything we are understating how fantastic EntitySpaces is at providing the glue between Silverlight and WCF.

From Mobile Devices to large scale enterprise solutions in need of serious transaction support, EntitySpaces can meet your needs. Whether you’re writing an ASP.NET application with Medium Trust requirements, a Mono application, or a Windows.Forms application, the EntitySpaces architecture is there for you. EntitySpaces is provider independent, which means that you can run the same binary code against any of the supported databases. EntitySpaces is available in both C# and VB.NET. EntitySpaces uses no reflection, no XML files, and sports a tiny foot print of less than 200k. Pound for pound, EntitySpaces is one tough, dependable .NET architecture.

EntitySpaces LLC
Persistence Layer and Business Objects for Microsoft .NET
http://www.entityspaces.net