How to serialize your XPO

Jul

2011

How to serialize your XPO

EDIT: I suppose technically this should be title, "Where to start if you want to serialize your XPO" as it doesn't actually tell you "How" per se, but gives you the general information on what you "can" serialize as such. Again, my wish to continue along this to provide more in depth information on actually "how" to serialize as well. All in due time.

Background

OK well, I am in the middle of rewriting our backend of our application (again). My first iteration of our application used .NET Remoting in .NET2 and was remoting the DataStore layer, this worked albeit with alot of limitations and wasn’t very reliable across the internet which is the primary network used with our application.

With the release of VS2010 and .NET4, I made the bold move and brought our application out of the dark ages and into the .NET4 world which could provide me benefits such as LINQ (as I was only with .NET2 I didn’t even have this), TPL (Task Parallel Programming) and of course WCF4.

This was a great decision as after the initial WCF learning curve the application has been much more reliable and performance improved as well.

The only downside that remained was the continued use of the IDataStore interface as my contract for communications. The IDataStore is very simple, and is all based around 2 main methods, SelectData and ModifyData. The issue you have from a n-tier point of view is at this level, the data being transmitted is basically table and/or query information. The objects to which they came from are long ago left behind in the stack.

Introducing IObjectLayer

With 2010.2, DevExpress included the early efforts of refactoring the XPO library to support a new “ObjectLayer”. As this was in it infancy I hadn’t been able to take the time to review this new functionality. However with 2011.1 the ObjectLayer has moved forward a little more, and now I can look into this new functionality of XPO and implement it to provide more Server side interactions.

This is a representation of the XPO object stack as of 2010.2, you will notice we first start with a UnitOfWork (well at least if you are following Best Practices). UnitOfWork is derived from the Session class, the Session class contains all the lower level code, while UnitOfWork handles the transaction operations. To create a Session we need to pass a IObjectLayer. Wait you say, I haven’t changed my code, I still pass a IDataLayer to my Session. This is correct, the ctor of the Session allows either IObjectLayer or IDataLayer, however if you pass the latter, the Session will automatically create a IObjectLayer from your IDataLayer. This means all Sessions are now using ObjectLayers and the ObjectLayer is talking to the DataLayer, then the DataLayer is what communicates to the IDataStore.

This now provides us with two options for Serialization, the original way is via the IDataStore, however the new approach is at the IObjectLayer.

DX provides an example

There is an example included in 11.1 which gives a basic understanding of how to use the IObjectLayer. This is located at

Windows Vista/7
%Public%\Documents\DevExpress 2011.1 Demos\Components\XPO\VB\XpoTutorials\ObjectLayerService
Windows XP
%ALLUSERSPROFILE%\Documents\DevExpress 2011.1 Demos\Components\XPO\VB\XpoTutorials\ObjectLayerService

Scenarios

I haven’t profiled it yet, however I would say that the IDataStore would be a more efficient contract (less data) than the IObjectLayer, however the IObjectLayer does allow for more greater control.

Possible uses of IObjectLayer

Auditing records on the Server Side (logging which fields are changing)
Security on field level, removing any changes on fields that the user is not allowed to adjust, or blanking fields being sent over the wire (such as credit cards etc)
Aggregating multiple databases, as a ObjectLayer can talk to another ObjectLayer, you could in theory setup two ObjectLayers on the server side that are connected to different DataLayer/DataStores and sending the combined result to the client.
Split databases, depending on logged user connect them to a different database
Probably alot more scenarios, these are just some off the top of my head

tldr

Since 10.2, Sessions are using IObjectLayer as a intermediate layer between the Session and DataLayer. This opens up new possibilities with n-tier communications providing a new serialization point in the XPO stack. Example is included in DX XPO Tutorials.

Conclusion

So what has this article provided? well nothing really other than letting you know about the ObjectLayer introduced in 10.2 and improved in 11.1, as I continue with my project I will blog about what I come across and particular scenarios.