In scenarios where a server application implemented with Genome needs to pass back state of persistent objects towards clients that do not have access to the underlying database server or may not use Genome, the server application would need to translate lazy-loaded Genome persistent objects into lightweight Data Transfer Objects (DTOs) representing a disconnected object model for wire communication purposes.
Doing so does not only mean translation from one object model to another but also requires the developer to reinterpret the communication interface between the client and the server. Using persistent objects in Genome provides certain features that would need to be taken care of when using DTOs.
Persistent objects in Genome are subject to lazy loading. This brings the advantage that the developer does never have to specify explicitly how much data should be retrieved by a given database query. As Genome intercepts all access to persistent objects it can always retrieve missing data from the database on demand. This however requires a permanent connection to the database and therefore cannot be supported in a Data Transfer Object. When returning DTOs to the client the caller must explicitly specify which related objects or object collections need to be returned along with the referring object.
Genome provides efficient update tracking services for persistent objects. Every update performed on a persistent object is intercepted by Genome and recorded in the Transactional State Buffer. Whenever the Context is committed Genome uses the Transactional State Buffer to perform database updates. As updates to a DTO happen outside of the scope of Genome these updates have to be detected manually whenever the client resubmits the updated DTO to the server by comparing it to the current database state of the persistent object. Although WOP provides certain support for detecting changes on the client side this is still far from the efficiency and convenience provided directly by Genome.
Genome provides various transactioning services for persistent objects such as optimistic or pessimistic object level locking. As in a message-based remoting scenario it is unpredictable how long will the client access the state of retrieved objects. And when (if at all) it will perform updates on these objects these services would need to be reinterpreted in the context of a DTO communication protocol. WOP provides means of optimistic locking for DTOs returned from Genome service applications.
While Genome provides effective object state caching for persistent objects, caching services would have to be reimplemented by the client application in case they are needed.
If the communication protocol between the server and the client uses WebServices, limitations imposed by the communication protocol itself constraint DTO classes as well. Database NULL values, circular object graphs, classes without a public default constructor, or classes having strong encapsulation using private or protected fields are issues that every DTO class model needs to deal with.