Why not use Hibernate beans as DTO in layered architecture

tex321 · **Joined:** Fri Oct 05, 2007 7:34 am **Posts:** 4

Hello.

I am wondering for some time, why majority is proposing DTO pattern for communication with presentation client in 3-tire architecture. Such solution is also described in hibernate wiki page as dominant.

Among others I read following conversations:
http://forum.hibernate.org/viewtopic.ph ... al&start=0
http://forum.hibernate.org/viewtopic.ph ... teexternal
http://forum.hibernate.org/viewtopic.ph ... teexternal
http://www.hibernate.org/124.html

Problem that bugs me the most is complexity of DTO objects. If ER model is complex, there are alot of different associations, that have associations, that have associations... Building such DTO framework with ability of transformation DTO <-> ORM takes some time. Same goes for sending graph data from client to server when you try to save DTO graph that comes from client to ORM graph. Why is it worth the time once it is implemented and used on several projects (doesn't same apply for Hibernate Bean DTOs)?

Off course there are some advantages with DTOs:
- composite data
- no lazy initialization error
- some method can be hidden from client
- ...

On the other hand you can override writeExternal and skip unitialized proxies with Hibernate.isInitalized(object) and just transfer Hibernate objects over wire. Maybe you can even build interface over ORM objects and return only wanted functionality to client. e.g.:

Code:

public class OrmObject1 implements ORMObj1Intf {
    
    public Set<OrmObject2> getOrmObject2s()
    {
       ...
    }

    public void setOrmObject2s(Set<OrmObject2>)
    {
    }

    public int getId() {
       ...
    }

    public setId(int id) {
       ...
    }

    public void serverBusinessMethod() {
       ...
    }
}

// hide business method from client
public interface OrmObj1Intf ()
{
    public void getId();
    public void setId(int id);
    public Set<OrmObject2Intf> getOrmObject2s();
    public void setOrmObject2s(Set<OrmObject2Intf> objs);
}

public interface OrmObj2Intf ()
{
...
}

public class OrmObj2() implements OrmObj2Intf
{
...
}

Does original Hibernate object stay in persistent context?

What are disadvantages of this approach for tranferring data? We give client different interface and also no DTO layer with Assemblers must be build. Maybe this approach could be used in Command pattern?

Thanks for your replies.

ericfkaufman · **Posted:** Wed Jan 16, 2008 10:58 pm

I've found that as I've progressed down the SOA road, DTO's are necassary, and are actually start to take the form of your "message" rather than resembling the persisted object that they reference.

For example, you might have Client, and then a Dto.Client or ClientDTO or whatever, whereby the DTO version uses arrays, hides some big collections, etc.

The next evolution I've been going through is that when you get right down to it, the best way to insert a Client is not by having a service method of ClientInsert(ClientDTO), but rather to do something like ClientInsert(NewClient), where NewClient contains only the properties you want to expose when inserting a new Client.

In short, once you turn your back on Hibernate (as in, you can stop stumbling over it and move on to new ways to improve your architecture because you know Hibernate like the back of your hand), the next thing you might want to engage in (atleast what I am) is improving your SOA.

For me, it means trying to go for chunky vs. chatty connections, and often that means creating types (soa: schemas) that have exactly what is needed for wire optimization.

It's a much different outlook, because you're built schemas from an SOA mindset, instead of basing them off of your business objects.

But absolutely if you're serializing to xml, there is absolutely no greater performance gain to be had than cutting down the chatter service calls. We consider it a job well done when a user interface operation (loading a Client, modifying one, loading an Invoice, etc), is handled with a single service call.

There's no way you'll achieve that unless you heavily engage in DTOs. There are massive performance gains to be had there.

damonf · **Joined:** Wed Dec 21, 2005 6:57 pm **Posts:** 70

Sure, you can do that. We use custom initializers to define different "scopes" of data to avoid having to eagerly load maximal data extents all the time. These custom initializaers know the data extent needed on the client for a particular request and ensure that any lazy relationships that need to be loaded get loaded on the server.

For queries we have to do some custom coding, however, since the exact subset of data for bulk operations does not match up well with the data that our cascade settings load. Some of this can be worked around with lazy/eager settings in the queries themselves, of course.

It depends a lot on which data is going to be a performance issue and which isn't. If you can use your existing POJOs you should of course do that to save time an energy, and put meaningful business logic in your pojos. (you may need to package some server-oriented libraries on your client, however, to get things to complile, because your POJOs may have server-oriented dependencies.

Alternatively, consider seam or ruby on rails, which uses "convention over configuration" to automatically copy data back and forth from your client to your server and on to your database, without having to hand code DTOs for every freakin' thing.