I just finished reading 312. Wouldn't it be possible to use clone() or copy constructors or something to have the best of both worlds? I mean the DTO would still be a POJO, but it wouldn't be a hibernate proxied class. ie. The LazyInitializationException would only happen during cloning.

IMHO, this is a DTO solution without a separate heirarchy. I don't need hibernate jars on my client as the client only receives POJO's.

Am I on crack? I am just a newb to this.
thanks,
dean



Hibernate version:

Mapping documents:

Code between sessionFactory.openSession() and session.close():

Full stack trace of any exception that occurs:

Name and version of the database you are using:

The generated SQL (show_sql=true):

Debug level Hibernate log excerpt:

just read p391's NOTE: Wouldn't it be possible to do clone()(underlying would probably be copy constructor of course) and then the hibernate libs would not have to exist client-side??? Does this not give the advantage of DTO without dual heirarchy??? complete newb asking. Of course, when someone went and invoked a persistence accessing method like getMaxBidAmount, it would result in a NoClassDefError which I would think would be acceptable as you only should be using the get/set methods on the presentation tier except maybe for some other minor methods like getName returning first and last name or something. thoughts????

Think about unitialized associations: on the client, you expect a useful exception if you try to access your graph beyond the loaded objects.

actually yes, I was thinking more of filling in default values or something, or I could even have my own preconditions in the POJO so at least I don't need hibernate jars client side. More importantly, as we have more and more webservices, I could marshal it to xml. In that case, I don't think I can really have hibernate jars on the client side as it might be .NET.

Either way, DTO's or hibernate detached objects, I do prefer one heirarchy and either way it seems you can't send the whole heirarchy of objects and have to at some point make a decision as to where the heirarchy ends. The end of the heirarch is either a DTO with no continuation on...which is sometimes a null object with no exception anyways from some of the DTO's I have seen.

I think the heirarchy either ends with nulls, or self made preconditions.

yes, yes, then the point is how to tell a difference between when something was supposed to be null vs. it being null because we didn't send the whole tree across. I think it might end up being a case by case basis. Sometimes, you could even have a default value that means basically there is more so you know when to throw the exception.

I don't have much experience here, but would think it wouldn't be that hard to accomplish. I guess I will find out soon while I experiment with this on my open source project.

A null would be semantically wrong. Null means "missing information" while an exception means "there might be something there, but its not loaded". Whats the problem with Hibernate libraries on the client? In every ORM implementation you need something on the client, no matter if its a small pojo-client.jar (we will release one for Hibernate soon) or the bytecode enhanced classes from the server.

one small client jar....hmmm. Nice, but I am developing a service exposed to .NET and Java clients. I must figure a way to make this clean if possible without having two heirarchies. JBoss I hear is coming out with a mapping technology for the xsd side of stuff that also does POJO's.

Even if I was doing binary, I could always choose to isolate from hibernate client side by having my own LazyInitException and then I wouldn't need the small client jar making life easier when I am forced into xml, which I am forced into now. All the hype around SOAP makes marketing think we have to have it. It entices those VP's to buy our products I guess. :(

Well, then customize the serialization and replace the Hibernate proxies with your own. It should be clear that you can not send them back and reattach them to a Hibernate Session though.