Package net.sf.mmm.util.transferobject.api

Provides the API for transfer-objects.

See: Description

Interface Summary

Interface	Description
TransferObject	This is the interface for a transfer-object.
TransferObjectUtil	This is the interface for a collection of utility functions to deal with AbstractTransferObjects.
TransferObjectUtilLimited	This is a limited subset of TransferObjectUtil that is GWT compatible.

Class Summary

Class	Description
AbstractTransferObject	This is the abstract base class for a TransferObject.
CompositeTo	This is the abstract base class for a composite TransferObject.
DataTo	This is the abstract base class for an TransferObject that only contains data without relations.
EntityTo<ID>	This is the abstract base class for an DTO corresponding to a PersistenceEntity.
EntityTo.PersistentEntityAccess	Inner class to grant access to internal PersistenceEntity reference of an EntityTo.

Package net.sf.mmm.util.transferobject.api Description

Provides the API for transfer-objects.

Transfer-object API

Provides the API and base classes for TransferObjects and utilities based on well-established concepts.
A PersistenceEntity often contains relations (see OneToOne, OneToMany ManyToOne , or ManyToMany). While a PersistenceEntity can make use of lazy loading this is not possible in TransferObject. Therefore you have to express which selection of your data model you want to transfer for services that load, save, update, delete or process data. If you would add all relations to your TransferObjects you might end up with one of the following problems:

• loading way too much data causing serious performance problems
• relations sometimes being available and sometimes being null without a transparent concept causing serious runtime errors.

Hence you want to avoid using relations in the same way in your TransferObjects. To avoid a naive way of doing this, this package introduces DTO, ETO, and CTO.
Example:
Assume you have the following entities:

Now you could build the following TOs:

• AddressTo with the attributes from Address.
• ContactInfoTo with the attributes from ContactInfo.
• AddressWithContactInfoTo with the attributes from both Address and ContactInfo.

Due to the lack of multi-inheritance in java, the latter case is a problem. Therefore you would have to duplicate the attributes from Address or ContactInfo (or both).
Therefore our recommendation is to solve this by creating the following TransferObjects:

• AddressEto extending EntityTo with the attributes from Address.
• ContactInfoEto extending EntityTo with the attributes from ContactInfo.
• AddressWithContactInfoCto extending CompositeTo containing AddressEto and ContactInfoEto.

If you separate persistence entities from TransferObjects then Address and ContactInfo should be an interfaces that centralize the JavaDoc for the attributes via the getter methods. Your EntityTo (e.g. AddressEto) and PersistenceEntity (e.g. AddressEntity) then both implement that interface (e.g. Address).
NOTE: