Hi,

I have an application currently using JDO that I want to migrate to Hibernate. We currently experience performance related problems with JDO and are considering changing the application architecture to use the Value Object pattern.

My question is, in hibernate is it recommended to create seperate value objects to transmit the data, or is it best to use the detached hibernate objects? Is is it not even neccasary to use this pattern? Is Hibernate quick enough without it. The application is a client server application with a centralized server. The clients connect to the server over a 512 mbs ADSL line.

Any help, suggestions would be greatly appreciated.

Regards,
Brian

Hi,
I've just done a pretty big migration from JDO to Hibernate. Our Application used DTOs (or Value Objects as you call them) with JDO and uses them now as well with Hibernate. We faced some problems due to Hibernate's byte code enhancement and Lazy Proxies since we transformed our domain objects to DTOs with reflection. Apart from that we had no problems with this kind of pattern. Of course you can send the detached objects to your client(s) with Hibernate but you have to be aware of uninitialized collections that are mapped as lazy. If you want to access one of these you will get a LazyInitalizationException.

Actually I prefer the DTO Pattern for bigger apps:
- You send a well defined data "snapshot" to the client
- You only send as much as you really need
- You maintain a higher stability of your interface to the client

As far as performance goes I would concentrate on effective queries / mappigns and good database tuning. I doubt that the VO Pattern has a major impact on performance.

Summary: In general the pattern is not mandatory with hibernate but there are some good reasons to go for it.

Hi Mike,

Thanks for the reply, I appreciate the comments. When you say you transformed your objects to DTO objects using reflection can you point me to any resources that explain how to do this? Also how do you then transform you DTO objects back when updating? It seems that this is then a manual process which can be very time consuming? Or is there a better way to do this?

Regards,
Brian

We are just facing the same problem but we think there is a big issue with DTOs / please consider the following scenario:

*We load data from the business layer, which includes lazy collections
*The objects returned bz Hibernate will be copied into DTOs
*The DTOs are transfered to the client where they are modified
*The modified DTOs will be sent back to the server
*Hibernate persists the changes

Problems:

*How do you copy the lazy objects without running into IazyInitializationException?
*How do you handle lazy collections? Set them to null or empty?
*How do you detect changes in the DTO - e.g. if a collection is set to null - how can you determine whether the client caused this or if the collection simply was not initialized before?

Regards,
Tom

We wrote an utilty class that works on naming conventions: if you need a field of your domain object you have to include it in your DTO..it is then being "copied" from the business object to the DTO. Same goes out to collections. For special cases we implemented hookpoints for manual "dto - bo mapping", especially when you wish not to go by naming convention. This class works fine for transitions in every direction. I know that this is kind of risky because you as a developer should not deal with the hibernate internals of lazy proxies or whatever. Due to the amount of DTOs and Business Objects (which would have ended in a time consuming / boring manual process) we chose to take the risk and did not regret it.

1) When you copy lazy collections you have to make sure that your hibernate session is still open (leave it open until the end of a transaction / service call)

2) When you need the collection in the DTO: load it. When you don't need it, don't include it in the DTO

3) Use Versioning and have a look at what I said at 2)

Hm, somebody could write a DTO assembler that reads domain classes and creates DTOs automatically.



This metadata could then be used by the assembler to create DTO snapshots automatically. No idea how this can be implemented, but possibly with:

- automatic generation of Snapshot subclasses at runtime (CGLIB, Javaassist)

- arbitrary combination of snapshots, e.g. new Snapshot("item", "customer") would add all properties that have @Assemble under their exposed name

- loose coupling with an expression language, e.g. snapshotAssembler.addProperty("customPropertyName", "#{item.itemPrice}");

And also a disassembler that converts back into regular entity instances. Does this sound like the SDO stuff?

Christian,
this sounds quite interesting to me and I think I have a good use case for something like that at my current customer (the reflection based utility class works but it is far from being "nice")...the problem is that they're using WebSphere (no Java 5 ... I hate it).

To get you right: your idea is to generate the DTOs at Runtime by developing an assembler that does all generation and the back and forth mapping of DTOs and Business Objects. What I did not quite understand was your idea regarding expression languages. Your idea with arbitrary combinations of snapshots is a very useful one as well.

The only problem that I see is that a client application would need jars with the DTOs. This could be circumvented by the usage of interfaces (which could be generated at build time)... Maybe I'm overlooking something right here...


I'm not so familiar with the SDO stuff yet (though I should look into it).

This was really just something that I came up with in 5 minutes, there are probably many problems with the implementation. For example, I wouldn't try this with external metadata, annotations are a great for this (so you'd need JDK 5).

The expression language allows you to bind a DTO property to an entity property dynamically. So whatever "item.buyer.customerNumber" refers to in the entity tree is the bound entity property, doesn't mean there has to be a real buyer and a real customerNumber property, just something that is exposed for assembly under that name.

I've last looked at SDO 2 years ago, AFAI remember there are likely overlapping use cases between an automatic DTO solution/assembler and what SDO does. That was also the time I thought CarrierWave had some excellent ideas: http://nadavwr.livejournal.com/8365.html?view=3245

Of course there are many problems with regards to the implementation / solution of this issue. I would not consider this kind of stuff to be a "quick shot" solution you just hack while refactoring your application, so I wouldn't mind not having JDK5 ... Basically the reflection based BO / DTO mappings are a pain to write as well and something like that would be a solution that is ways more transparent and nicer... I would see the development of such a utility in more stages:

1) Provide means to do back and forth DTO - BO Mapping with annotations and EL support (in a very basic way)
2) Automatic DTO Generation with CGLIB / JAVASSIST
3) Arbitrary combination of snapshots and other features

I think I'll spend some hours of my free day on this idea...

If things go well I'll be at JBoss World Berlin, I plan on proposing a case study of our JDO -> Hibernate move (which was a big success for our customer) for the conference ... so we might have a chance on chatting a bit on this idea (or a raw implementation that I would really fancy to try)

I really do not like the entire idea of DTOs - I think that they are unnecessary, add a performance loss and in the case of Hibernate just cover up a design issue (lazy collections). Don't get me wrong - of course, lazy loading is important and Hibernate is a great framework but once you start having detached objects that are passed around in your web/rich-client-tier it's very akward, because you start running into LazyInitializationExceptions, especially on bigger projetcs, where a larger number of people are involved. Why should I have to worry about LazyInitializationExceptions in my frontend? This is a concern of the DataAccessLayer and should be handled there. In my opinion, OSIV is not really a solution, because it does not really address the problem - it merely hides it.

Anyway, we are trying to solve this problem with AOP, which is a better approach than using DTOs in my eyes. Basically we detect if we are running on the client, if so we check access to all lazy associations and only return them if they are initialized. By doing this we can pass our DOM objects directly to the client and do not have to worry about getting LazyInitializationExceptions.It looks promising, at least so far,

Regards,
Tom

de_tom,
I agree with you on the point regarding LazyInitExceptions, but I think you (as a developer of business logic) gain more flexibility with the DTO Pattern, especially if there is a different (esp. locally) team developing the client application. It gives you the freedom to change things in your domain model and you don't need to propagate them to your client application.

Hi Mike,

is there really such a thing as a DTO Pattern? I think DTOs were just introduced as a result of shortcomings of various frameworks, which makes them a necessary evil yet not a pattern.

In my opinion, it would be best if Hibernate could take care of providing pure POJOs when needed, eliminating the need for DTOs or AOP enhancements altogether.

I am not sure, that it is really good to have a DTO layer in between your business layer and your presentation layer. Basically you are facing the same problems as in the view (LazyInitExceptions) plus you have to propagate changes made to the DTO back to your Domain Model. Of course, there are certainly situations, where DTOs come in handy yet unfortunately this is not true in our case.

Regards,
Tom

I am facing similar problems and have not found a good solution, yet. It seems to be clear that using DTO has pros and cons, depending a lot on the usecase.

Right now I am trying to use the Hibernate pojos both on backend and frontend (otherwise I would have to create about 400 DTOs). Transport format is a nested list, much like Hibernates "map" mode but without the property names. This format is assembled and disassembled via reflection, using the getters and setters. This process works recursively to visit the whole object graph. However, it should stop at uninitialized properties. How can I detect whether a given property of an object is not yet initialized? If I access it via the getter is initialized first...

I guess it would also be helpful if there was a way to transform a pojo into its Hibernate map representation.

DC

Never mind, this was a misconception on my part. I can call the getters just fine without triggering initialization and can then use Hibernate.isInitialized() on the return object. Exactly what I wanted. I was confused by Hibernate.isPropertyInitialized() which does not do what I thought it would. Consider this:

SomeEntity e = session.get(SomeEntity.class, 123);
boolean b1 = Hibernate.isInitialized(e.getSomeProp());
boolean b2 = Hibernate.isPropertyInitialized(e, "someProp");

I was under the impression that b1 == b2 after this, but actually b2 is always true (looking at the code I suppose it is only useful when lazy fields are used).