What are the problems associated with sending a Hibernate Proxy class to clients.

Question

I have a POCO classes that I am using with NHibernate in a WCF service layer. And I am thinking about trying to send the NHibernate proxy classes down to a client. This is a client that I control. We handle record updates with a system wide reservation so there can only be one writable copy of this entity sent to a client at any given time. My basic goal is to take advantage of NHibernates change tracking so I don't need to fetch a copy from the database and replay the changes the client made to update the db.

Assuming I could get this to work what are the cons of this approch?

Answer 1

I'm not going to answer the question in terms of the specific technology, but I hope you find this point of view useful in making some decisions.

IMHO (and those of people who follow Domain-driven Design) you should keep your entity types internal and, thus, separate from your service types (aka value types). Very often entities are far too granular for a service interface anyway. For example, you may want to return a result from an operation at the service layer that is actually the combination of disparate pieces of data in your entity model. Not only that, but not all fields of an entity are necessarily intended to be directly mutable by the client. Also, if you start exposing your entitiy types directly you are in danger of marrying yourself to the underlying database structures which, over the course of time, may need to be refactored for scalability reasons. By separating your service's value types from the underlying entities that populate them you give yourself an imortant layer of flexability.

The downside is you're writing a lot of value types which are basically "empty shells" inside the service domain that usually look a lot like the entity types inside your data access layer. Plus you need mapping functions to translate values back and forth between the two types. To me, this is a small price to pay for the flexability that is provided down the road.

Answer 2

Lazy-loading will give you the biggest headache.

Some of the properties on your objects will contain NHibernate proxies, which are attached to the ISession. All of this will travel back to the client. When the client attempts to deserialise your objects, the proxies get invoked and attempt to retrieve more data. BOOM!

There are several workarounds people have posted (Google "nhibernate wcf" or "nhibernate wcf lazy loading"):

http://lunaverse.wordpress.com/2007/05/09/remoting-using-wcf-and-nhibernate/

http://timvasil.com/blog14/post/2008/02/WCF-serialization-with-NHibernate.aspx

http://whiletrue.nl/blog/?p=37

http://trentacular.com/2009/08/how-to-use-nhibernate-lazy-initializing-proxies-with-web-services-or-wcf/

I'm currently working on swapping out the proxies with custom ones, so they make a WCF call instead of triggering the Nhibernate lazy-load.