The only reason they are initialized is for the Spring binder to work properly using them as command objects. This to me seems like a pretty good reason not to use Hibernate entities as command objects
The only reason they are initialized is for the Spring binder to work properly using them as command objects. This to me seems like a pretty good reason not to use Hibernate entities as command objects
As I implied when saying it is already an error on the Java level: It has nothing to do with Hibernate. You would get the same error with DTOs. In your case it seems to be better to put that code into the controller instead of the domain objects, especially since it is a requirement of the web framework, not your domain.
Joerg
This post can contain insufficient information.
This might have been repeated before but wanted to run by to see that my assumptions are correct
Deciding whether to use DTO's or not to use them have been bothering me before I started my current work. And having known some of the issues with this approach, I've used my domain objects in the presentation layer.
But, have reached a stage where in I'm regretting my choice of doing it.
The problem mainly is when using domain entities (with one-to-one relation to other entities) in presentation layer (JSF). When the child entity is not available for the parent entity, it would be set to null by the ORM. This causes the problem because the binding on the presentation layer (JSF) calls some setters on the nested child entity and that throws "null" validation problems.
I think DTO's are required if the domain entities are editable from presentation layer. DTO's could be ignored for entities that might be used for only rendering info. Agreeing to what was said in the Hibernate in Action book.
Any feedback is much appreciated.
Just do it. I have finished this thought.
http://code.google.com/p/rich-hibernate-lazy/