Transfer Obejcts vs Business Objects (JPA entities) across the tiers

Introduction

In this article I try to launch a very common technical discussion about what is the best approach, Transfer objects or Business objects (JPA entities) across the tiers. Once more time, I think that there is no a golden rule. It depends on the use case, the complexity of the application in terms of architecture and frameworks used.

Transfer Object across the tiers

Pros

1. Reduces network traffic in distributed systems. Transfer objects are passed to the client in a single remote call.

2. Improves client performance by removing any need to assemble data models.

3. Decouples business logic from the client and keeps it in the business tier.

4. Improves transaction performance by isolating the components that can be updated.

Cons

1. 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.

2. The system can be complicated when using concurrent access or transaction management processes.

3. 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

Pros

1. Good approach in simple presentation tier design.

2. Makes easier the development in business and presentation tier because there is no need to assemble data models.

Cons

1. 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.

2. In the case that the user interface requires a complex set of properties:

2.1. The domain model to pass across tiers can become heavyweight in terms of memory.

2.2. The development in the presentation tier can be complex because we need to navigate across multiple business objects to get the properties.

2.3. 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:

      

       2.3.1 In business tier: Eager relationships in JPA entities.

       2.3.2 In business tier: “Fetch Join” in application services.


      Note: Some frameworks keep transaction opened during the render of the user interface.         
      In the case the relationships in the JPA entities can be defined as LAZY. We do not have      
      to be worry about exceptions as org.hibernate.LazyInitializationException in the case of      
      using Hibernate as JPA provider.