Transfer Obejcts vs Business Objects - Which Approach Works Best?

Alvaro,

Ik think the cons of the business objects provide the answer on why you would never pass objects through the various layers over your application model. When usig the JPA implementation you suggest you are not only tying your presentation tier to the business tier but actually to the data access tier. 

Besides the obvoius point you already point out, one of teh more desturbing things that you allow is direct manipulation of objects (data) that resides in the database from the presentation model. You got to be very sure that the presentation layer does not messes up the database.

I belive in the assumption that the seperation of concerns is key to a good design. And yes when you have a simple application that has a short live time, the straigh passthrough the layers is no problem ;-). The only question left now define simple and short lived ;-)

Posted a reply here... There is room for both, I think...

 I do think there is a sliding scale where it is permissible to use persistence objects in the presentation tier.

Cons

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

 You forgot to mention the imho biggst drawback of passing Entities around:

It is only possible with dumb JavaBeans, so it encourages an "anemic domain model" where the so called Domain Objects/Entites are nothing more than data structures instead of real objects with behaviour.

You won't be able to use DDD or any other OO Design for your App, but are stuck with the old, procedural style of design that Fowler calls "Transaction Script", all the Logic ends up in your SessionBeans, which uses Daos and the Entities to perform their job.

That ain't bad in all cases, however, it is an serious limitation if you wanted to go DDD, since in DDD your Entites would have logic & references to the repositories (Daos) to perform their job.

There is no need for creating complex DTOs or different DTOs per UseCase by hand, use Dozer, a Framework that will Map your Beans to whatever you want, like Maps.

@TransferProxy
public interface ISomeEntity {
    long getId();
    void setId(long id);
    List< ISomeEntityChild > getChilds();
    void setChilds(List< ISomeEntityChild > childs);}

@Entity
@ProxyBindings ({
    @ProxyBinding(interfaceClass = ISomeEntity.class)
})
public class SomeEntity implements Serializable {
    private long id;
    private List<SomeEntityChild> childs = new ArrayList<SomeEntityChild>();
	private List<SomeEntityAnotherChild> anotherChilds = new ArrayList<SomeEntityAnotherChild>();
	
    public long getId() {
        return id;
    }
    public void setId(long id) {
        this.id = id;
    }
    public List<SomeEntityChild> getChilds() {
        return childs;
    }
    public void setChilds(List<SomeEntityChild> childs) {
        this.childs = childs;
    }
    public List<SomeEntityAnotherChild> getAnotherChilds() {
        return anotherChilds;
    }
    public void setAnotherChilds(List<SomeEntityAnotherChild> anotherChilds) {
        this.anotherChilds = anotherChilds;
    }
}

@TransferProxy
public interface ISomeEntityChild {
    long getId();
    void setId(long id);
}

@Entity
@ProxyBindings ({
    @ProxyBinding(interfaceClass = ISomeEntityChild.class)
})
public class SomeEntityChild implements Serializable {
    private long id;
    public long getId() {
        return id;
    }
    public void setId(long id) {
        this.id = id;
    }
}

@Entity
public class SomeEntityAnotherChild implements Serializable {
    private long id;
    public long getId() {
        return id;
    }
    public void setId(long id) {
        this.id = id;
    }
}

@alvarovilaplana - It depends. But First -DTOs contain the same amount of Data as an entity.  That is the DTO pattern. IF you only select certain attributes of different entities, then this is not a DTO. It is something like a (readonly) view model. Now back to the "depends".  For viewing in a list, I might use a ViewModel or "Report Object" and only retrieve the attributes i care about. I could have one or more objects. I need to weigh the effort vs savings.  I build these objects by doing a "select new SomeObject(a.field, b.field) from ...." For Look up objects, I typically just return those objects.  The reason for doing this has much less to to with network issues and more with databases. If the object tree is pretty simple I don't waste time with View Models. 

So the short of it is .. there is no right answer. You need to be or find a good architect to help you make the right decisions. And guess what - down the road you might have to make a change.

One issue I have run into is using something like GWT or Flex. These force me to use more ViewModels than i would like.

 @Everyone who talks about the "tiers". The view/database/etc are not "tiers". They are layers. I have apps that have multiple layers but run on one "tier".

>  But First -DTOs contain the same amount of Data as an entity

Hmmm, there might be a bit more to this in that ... entities can be "partially" populated. Some ORM's provide this via "fetch groups" ... in Ebean ORM you can specify explicitly which properties you want as part of the query language.

> I build these objects by doing a "select new SomeObject(a.field, b.field) from ...."

Yes, except it is not quite the same as a "partial object" ... where you re-use your existing model (don't need to define a new SomeObject) and your partially populated bean is still updatable and can still lazy load etc.

What this means to me ... is that it would potentially be nice to make the entity -> DTO transfer aware of the "partially populated" entity so that the transfer itself didn't invoke lazy loading un-necessarily (aka make use of the underlying "fetch groups" or "partial objects" support of the underlying ORM.

 - Rob.

Hmmm, there might be a bit more to this in that ... entities can be "partially" populated. Some ORM's provide this via "fetch groups" ... in Ebean ORM you can specify explicitly which properties you want as part of the query language.

So Entities can actually be MORE efficient that DTO's? LOL.  Anyway, I would avoid "partially loaded" entities. Use a veiw object or the other things I mentioned - if you need attributes from a complex object graph.  I've worked with partially loaded DTO's. A total pain.  

Yes, except it is not quite the same as a "partial object" ... where you re-use your existing model (don't need to define a new SomeObject) and your partially populated bean is still updatable and can still lazy load etc. 

 As I said, I use where i have to. Using partially loaded objects leads to big issues especially when working in a distributed environment. This is how most of my applications are. They also have different User and System Interfaces.  If all you have is a Web interface (and you are not using GWT), I can see you being able to use your technique if the the attributes are "lazy loaded" too. If not, then not.

> Using partially loaded objects leads to big issues especially when working in a distributed environment.

I curious as to what "big issues" you had with partial objects. Yes, in a distributed environment it gets more tricky but that depends on a lot of things such as use of 'enhancement', the serialisation method and the functionality you want on the 'remote' side.

Can you list the major issues you hit?

Thanks, Rob.