I definitely agree on that. The larger the application the more the need for an extra layer decoupling the clients from the service. What I have in mind are medium sized (web-) apps accessing stateless session EJBs.

with DTOs I really meant dumb data objects with no (or little) behaviour. Of course, if you add behaviour then they get their right to exist.

The question I'm trying to figure out is why not have POJOs for my domain model and use them both *before* AND *behind* my session EJB facade. Behind the session facade I use DAOs (with Hibernate) to persist and query my POJOs. Before the session facade I use DAOs that encapsulate access to my session facade. So I have my POJOs with a DAO for the client side and a DAO for the server side (and a DAO for unit testing!).




[/quote]

sorry, I forget the quote:

with DTOs I really meant dumb data objects with no (or little) behaviour. Of course, if you add behaviour then they get their right to exist.

sorry, I forget the quote
Also note that nothing stops you from having "actions" on DTOs, (they are no longer DTOs...).
With DTOs I really meant dumb data objects with no (or little) behaviour. Of course, if you add behaviour then they get their right to exist.

pm4ji, newbie here, oo non db type.

[quote="RobJellinghaus"]Here are *all* the divisions that I have heard of:

>1) The basic Hibernate classes (i.e. persistent POJOs that Hibernate manages). (If this is all you have, it's potentially the "anemic domain model" as per Fowler.)

well, it does have a bunch of relations, so it sems a bit more than a pojo/plain bean.

>2) Subclasses of (or behavior enhancements to) the basic persistent POJOs, to create a richer domain model.

why not add the code to the pojo. keep two branches and merge as the tables change?

>3) Data access objects (DAOs) which contain Hibernate-specific HQL. Typically your domain model methods (from #2) use your DAOs in order to keep Hibernate-specific code from leaking into your domain model. ...

ah, this is why you subclas the above? might delegation work better in some case?

> ... The idea is that #1 and #2 are generic code -- there's actually little or no Hibernate-specific code in #1 or #2 -- so you keep all the Hibernate-specific code in DAOs which are *used* by your business logic (#2).

by dao, you mean something like http://www.ociweb.com/jnb/jnbNov2003.html or more like http://java.sun.com/blueprints/corej2ee ... bject.html or spring?

>4) Data transfer objects (DTOs) used to pass data from the domain model out to the view / client layer. Some people think these ... so why bother with #4? Just use #1.

>My proposal above highlights some problems with just using #1 to pass data out of your service layer (namely that if you expose #1, you also have to expose #2). So my proposal lets you automatically create a DTO layer (#4) that is structurally identical to your persistent objects (#1), so you only need to write some generic mapping code and never customize it again.

>So, basically, the reasons for each layer:

>#1: Simple Persistent Beans. You have to have this layer for Hibernate to work at all :-)
>#2: Behavior-Enhanced Persistent Beans. You want to add interesting business logic to your Simple Persistent Beans, but you also want to be able to change your data model without having to rewrite your bean code. So you subclass your #1 objects.
>#3: Data Access Objects. You want your #1 and #2 layers to stay free of Hibernate-specific code, so you put all the Hibernate-specific code in separate objects which you use from your #2 methods.
>#4: DTOs. You want to hide your view clients from the structure and/or the business logic of your #1/#2 objects.

interesting approach

thanks

Because the merging would be a huge pain in the rear and very error-prone. Using <meta generated-class> lets subclassing do the work, and means that when you change the generated code / mappings, javac will tell you which bits of your subclass behavior code need to change. We have been using this technique for a month or so now and it is truly wonderful.


No, the subclassing above is just to separate the generated code (in an abstract <meta generated-class> superclass) from the custom behavior (in the concrete subclass which we write and which Hibernate maps). In some sense, putting the HQL into DAOs is kind of like delegating to the DAOs for all Hibernate-specific operations, though, yes.


Hmm, I guess neither. I really just mean a Finder-like object which encapsulates all querying or other Hibernate-specific APIs. We have taken the basic save, update, flush, etc. operations and put them in a generic wrapper, so we call that freely throughout the code. The "DAOs" only encapsulate the HQL.


Actually we aren't doing this at this point -- we're just sending out the domain objects. This is not a problem thus far since we are writing all the clients. We're keeping the "generate the DTOs" pattern in our back pocket in case we need it later.

Cheers!
Rob

most of our stuff #1/#2 objects can be given directly to the client, but there will be some fat controll classses (e.g. ManglePO) that may need some dto's

thanks for you clarifications. i am a newbie to db and biz illogic so this is very helpful.

Yes. The pattern is:

Then hbm2java spits out your/generated/MappedClassGen.java:

And *you* write your/MappedClass.java:


You put your code in MappedClass.java, and you regenerate MappedClassGen.java whenever the mapping changes. It makes no sense to put your code in the generated .java file because, well, it's *generated*! :-) And you want to be able to *regenerate* it without messing with your handwritten .java files. Feel free to show your boss this thread ;-)


Yes, this is exactly what happens: Hibernate at runtime *only* knows about your "your.MappedClass" derived class (since that's what your <class> element actually maps).

The generated class is just an implementation detail which hbm2java happens to make for you; you (and Hibernate) never make instances of it (it's abstract!), you (and Hibernate) only ever make instances of your concrete subclass.


I guess traditionally they do, but with Hibernate, you create objects with "mappee = new MappedClass(...); session.save(mappee)", you update them with "session.update(mappee)", and you delete them with "session.delete(mappee)". We have a Persistence static object which uses the thread-local-session pattern to hide the Hibernate details; so our code just does "Persistence.save(mappee)", "Persistence.update(mappee)", "Persistence.delete(mappee)", "Persistence.flush()". Presto, you can do CUD operations from any code. Then the R is the only Hibernate-specific part, so it's the only thing you need to hide in a DAO.


Should be no problem. Will be a bit of by-hand coding perhaps but if you only need it in a few places it should be straightforward.


You're welcome! Many people here helped me a great deal when I was a Hibernate newbie back in January....

Cheers!
Rob

CarrierWave - sounds similar to xdoclet...what are the differences??

Has anybody ever tried using clone() so the hibernate object just becomes a copy that is sent back to the client...(it at least eliminates needing hibernate jars on the client app).

Is this a really bad idea? It is coming from someone with 0 experience.
thanks,
dean

Hi!
And what about buildinng a layer on top of Hibernate that provides
services such as:

# automatic connection handling
# automatic transactions handling
# multiple undo levels
# real nested transactions
# client and server objects
# distributed non-transactional lazy loading
# etc,etc

That layer would have an an API like http://developer.apple.com/documentatio ... e_Objects/
or like http://bdn.borland.com/delphi/eco that would make IMHO unnecessary to worry about DTOs don't you think? (Something like the ECOSpace... perhaps NHibernateSpace? NHibernateObjectContext?)

I too have become frustrated with the DTO pattern and would prefer to send objects from the same server-side model back to the client rather than constructing a DTO. Sending an initialized graph of object back to the client would be ideal. Of course here, the trick is getting the graph properly initialized before being sent to the client. I have had some luck doing this using a ResultTransformer, but it is tedious work.

While I think some of what luxspes suggests is a wee-bit over the top, if there were an easier way to handle lazy-loading when persistent object have been sent to the client tier. I don't think this is probably the best solution as it would obviously unnecessary complexity to Hibernate. However, a nice to way handle graph initialization for the data that you need on the client would be a big help.

Ryan-

Hi!
Yes, I just dont get why the DTO pattern is so popular... for me is like the "ObjectContext" (ObjectSpace?) idea just got forgotten...

Why can't Hibernate just load objects on demand?

I mean, of course Session/Factory gives us more control... and ADO.NET or JDBC Api gives or even more... the close we get to the database, the control we get over it is greater... but.. is it always better?

Specially for Heavy/SmartClients wouldnt it be nice if we could have an HibernateContext that would transparently handle connections, session, transactions and uniquing? (Or course that API would have to be designed so that the HibernateContext could be overriden for particular places where extra power is needed.

A layer such as the one describe here: http://www.myecospace.net/Eco3Services.pdf

I am not saying we need a layer exactly like this, but I think we do need something similar, and, having Hibernate as the fundation, building something like that maybe wont be extreamly hard... I specially feel that an API for transaction handling similar to the "THE UNDO SERVICE" and "THE PERSISTENCE SERVICE" described in the linked pdf document, could make many tasks a lot easier...