We have decided to use the WCF DataContract approach when serializing our enhanced DynamicQuery’s. In our upcoming alpha release, our DynamicQuery classes now live in a separate assembly that can execute on the client side along with your EntitySpaces proxies without requiring either the EntitySpaces.Core or the EntitySpaces.Interfaces assemblies. The EntitySpaces.DynamicQuery assembly (only 52k in size) is also compatible with Silverlight and can run down inside of the browser. The older .NET 2.0 serialization techniques aren’t supported under Silverlight and having this feature work under Silverlight is important to us. At this moment, the Alpha will require .NET 3.5 SP1 (if you want to use these advanced new features) as it provides the ability to serialize object graphs having circular references. Currently, our DynamicQuery API does have circular references. For instance, SelectColumns have a reference to their parent DynamicQuery object. There is a very good summary of this feature in .NET 3.5 SP1 HERE and you might want to take a look at it. More on this later however.

Take a look at this very simple query. The example code below shows a query that will ultimately do a join and is selecting columns from both the Employees and Products tables. We also call ToLower, Substring, and Sum.

ProductsQuery prod = new ProductsQuery();

EmployeesQuery emp = new EmployeesQuery();
emp.Select(emp.LastName.ToLower().Substring(2, 4), prod.QuantityPerUnit.Sum().As("Qty"), emp.FirstName);

Here is an example of what one of the internal classes in our DynamicQuery API looks like. It’s ugly because we have to use #if #else #endif syntax, but just be glad you guys never have to write such code. We need to make sure the old and the new serialization both work. Notice the DataContract and DataMember attributes. Again, these are on our internal DynamicQuery API classes. Also, don’t let the WCF term scare you, these features can be used in non WCF scenarios as well.

Below is some test code that we use to manually invoke the DataContractSerializer.

List<System.Type> types = new List<System.Type>();
types.Add(typeof(ProductsQuery));

DataContractSerializer dcs = new DataContractSerializer(typeof(EmployeesQuery), "Query", "es", types);
var ms = new MemoryStream();
dcs.WriteObject(ms, q);
ms.Seek(0, SeekOrigin.Begin);

StreamReader sr = new StreamReader(ms);
string xml = sr.ReadToEnd();

Now, if you want to see what the resulting XML looks like click on this LINK. Admittedly, the XML is pretty funky because it creates what are essentially pointers to objects that appear in the XML graph multiple times. However, this saves a ton of space and of course prevents an endless loop when trying to serialize circular references.

Our development test harness for this is shown below:

Of course, when serializing and sending queries in XML over the wire, you are probably going to want to be using HTTPS so that sensitive data cannot be seen or tampered with.

What does this all mean?

Well, this means that our DynamicQuery’s can optionally be built into your proxy objects and used from the client side just as you would on the server side, only you will send your query over to the server and it will return either a proxy entity or proxy collection. Using our proxies with built in queries will feel like full blown EntitySpaces on the client side. And this will all run under Silverlight as well. Couple that with the massive improvements coming in our DynamicQuery API and that is some very cool functionality. Even if you aren’t interested in all this client side serialization stuff, you will love the enhancements coming in the DynamicQuery API. And remember, this will all work for web services too.

Before we release to production, we might be able to eliminate the circular references in our DynamicQuery object graph, however, this is not an easy thing to do. We do have a working solution via the enhancements in the .NET 3.5 SP1 release with the circular references in place.

Breaking Changes?

We are renaming quite a few internal classes. Some of them are public. For instance, esWhereItem is now called esComparison and esSelectItem is now called esExpression. Our queries are basically made up of esExpressions which are then combined with operators such as != or == to form esComparisons. The reason we needed to change these names is that they were too specific. We are going to allow you to use complex syntaxes in OrderBy, GroupBy and many other areas within the query syntax itself. Therefore, esWhereItem and esSelectItem just weren’t appropriate names. Most of you never really manually create these objects so it wont impact you at all. However, if you do, you will have to do a find/replace on these if you are manually creating them in code (which is rare).

Where are we at?

We are pushing very hard for our Alpha release to be released by the end of this month. Right now the carburetor is lying on the floor and we’re all absolutely covered in grease. However, we know how to put this back together again and when we do it’s going to be awesome. We are really excited about this release and the Q2 Wish List Forum will play, and is playing, heavily into what we deliver.

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