Transfer Obejcts vs Business Objects - Which Approach Works Best?
Transfer Object across the tiers
- Reduces network traffic in distributed systems. Transfer objects are passed to the client in a single remote call.
- Improves client performance by removing any need to assemble data models.
- Decouples business logic from the client and keeps it in the business tier.
- Improves transaction performance by isolating the components that can be updated.
- Data in transfer objects might get obsolete. The transfer object has a copy of the data which is not automatically updated if the data changes on the server.
- The system can be complicated when using concurrent access or transaction management processes.
- Synchronization logic can complicate the system if updatable transfer objects are used.
Object creation overhead on the server side increases.
Business Object across the tiers
- Good approach in simple presentation tier design.
- Makes easier the development in business and presentation tier because there is no need to assemble data models.
- Couples presentation tier and business tier. (Note: If the business requirements don’t change often I consider that is good point to use them but otherwise it could be a nightmare for each single change to adapt the presentation tier.)
- In the case that the user interface requires a complex set of properties, passing the domain model across the tiers can become heavyweight in terms of memory.
- The development in the presentation tier can be complex because we need to navigate across multiple business objects to get the properties.
- The development in business tier can become very tedious because we will load a lot of properties in the domain model (properties from BO1 -> properties from BO2 -> properties from BO3 and so on). There are two approaches to have all the properties in presentation tier:
- In business tier: Eager relationships in JPA entities.
- In business tier: “Fetch Join” in application services.
Note: Some frameworks keep transaction opened during the render of the user interface.
When relationships in the JPA entities can be defined as LAZY, we don't have to worry about exceptions such as org.hibernate.LazyInitializationException when using Hibernate as JPA provider.
What are your thoughts? Has any one particular approach worked better for you?
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)