Shh... IT in progress.

DevExpress XPO and .NET Remoting, a perfect match

User Rating: / 0
PoorBest 

Background:eXpress Persistent Objects (XPO) is a Object Relation Mapping (ORM) solution provided by DevExpress (DX), XPO is a Object->Database model (ie. You create strongly typed objects to which XPO will handle the persistance to a database store). XPO supports persisting to 16databases out of the box (although you can easily extend their DataStore classes to gain support for your database). See here for more details http://www.devexpress.com/Help/?document=XPO

I have a Client/Server distributed application that is required to work over the Internet and LAN. I previously handle all my traffic over a ASMX WebService using DataSets and generated my own code to “persist” records. It was crude and unfortunately didn’t perform very well, it was very bloated mainly due to theway that you have to serialise DataSets instead of DataTables/Rows. I needed to “re-develop” my communication backend. I started doing up a prototype, I generated classes from my legacy database system using the “Generate Persistent Class for an existing Database” and then successfully setup XPO over .NET Remoting using information provided by DX Oliver http://community.devexpress.com/blogs/xpo/archive/2006/04/20/51.aspx.

As I would be communicating over both LAN and Internet, I had major concerns of bandwidth usage. Using NetLimiter I could monitor data usage and gauge the performance by limiting network traffic usually at a worst case scenario of 5kbps. I found that the traffic generated from XPO was quite minimal. I was still keen on “squeezing” anything I could out of it, so I looked into Compression over .NET Remoting.

Remoting allows you to have multiple Sink Providers in the chain to perform a task on the channel traffic. After searching around I found this on CodeProject http://www.codeproject.com/KB/IP/remotingcompression.aspx which was perfect. I implemented this and found it helped improve things even more, in one test (loading about 20,000 objects of about 20 fields) I got the data transfer from 1610KB to 620KB with only a small CPU performance hit.

After further testing I learnt more about XPO objects and the different XPO classes available. Initiall I used XPCollections which returns a collection of Objects out of the database (similar to a SELECT * FROM Table command), Normally this is fine however in situation of wanting just a list of Usernames and their ID’s it was too much traffic for my liking. Another situation I encounted is when I wanted to display a Related fields Property it would then have to go out and load that object as well. (Pseudo Code, SELECT * FROM ParentTable then for each parent row a SELECT * FROM ChildTableWHERE ChildID=Parent.ChildID), this seemed too expensive for a listing of an object like a Sale where you only want to display the (SaleID, SaleDate, Customer.Company, Status.Title, Type.Title)

After more research I found that XPView allows you to return a “Value” collection of pre-defined fields (including Aggregates and Related fields) such as the Sale example above. In one particular test of showing 49 records I reduced the list from 89kb down to 6kb. The trade off is the grid is ReadOnly, however in my scenario that is fine.

I looked at DX Olivers other blog http://community.devexpress.com/blogs/xpo/archive/2006/10/13/388.aspx which wrapped up the XPO .NET Remoting solution into a neat class that allowed simple configuration by a custom XML file. I have been delving into it and seeing if I could make it have compression and also allow me to host more than one .NET Remoting Object on a single port/channel. I have had success and will be posting hopefully by the middle of September a run down of what I found and how I made it work for me.