Persistent Objects and DAOs

deyanp · **Joined:** Fri Nov 21, 2003 11:22 am **Posts:** 16

Hi,

Straight to the problem ...

Should a Persistent/Domain/Business Object call a method of a DAO object passing to it another Persistent object as an argument or not? The question is in the context of an application arhitecture consisting of a DAO layer, Domain Model Layer, perhaps Service layer and UI.

I have been reading this thread http://forum.hibernate.org/old/898425.html for several times now, and there I can see statements like
business <--- mappers ---> database (Stephen Molitor)
The DAO knows about the domain class; never the other way around! (Gavin King)

It seems that I am misunderstanding the above to the extreme that the business layer should have no reference at all to the DAO/mappers layer. Maybe a business/persistent object should still call the mappers/DAOs, but simply passing/getting other objects to/from the DAO methods, and not itself?

I would appreciate extremely all your feedback so that I can finally clarify this troubling me for a long time now problem!

Best regards,
Deyan

emmanuel · **Posted:** Tue Jan 06, 2004 12:58 pm

Basicaly, you have a DAO using hibernate and manipulating you business objects.
You have you business model knowing nothing about anything
You have a business process layer manipulating business objects and daos to make it work.
Your UI call this process layer.

deyanp · **Joined:** Fri Nov 21, 2003 11:22 am **Posts:** 16

Hi,

So effectively you say that the business objects should never call DAO objects' methods? How can one business object then "find" another unrelated one? How can a User find a certain Department for example? Or you first retrieve both the User and the Department in the business process layer(is this the same as the Fowler's Service layer?) and then pass the Department to the User? Isn't this limiting to the amount of logic you can put in the OO business model, hence forcing to use more procedural code, located in the business process model?
The problem that I am encountering currently is that I started exactly in this way, letting the domain model know absolutely nothing about the DAO layer ... but then I had to put a lot of code in the Service layer, as I have to always go back(from within a business model method chain) up to the surface(which is the service layer) every time when I need to call the DAOs :(

Best regards,
Deyan

emmanuel · **Posted:** Tue Jan 06, 2004 1:33 pm

finder methods are usually in a MyObjectDAO, and yes it somehow breaks the dynamic usage of OO, not the static one hownever.

deyanp · **Joined:** Fri Nov 21, 2003 11:22 am **Posts:** 16

So, do you say that the business objects should still be able to call the DAOs(directly or via interface & factory)? Or you mean that this limitation should be accepted and for the sake of purity of the business objects they should not do the above? Would you please elaborate on the dynamic vs static usage of OO?

Thanks a lot for your help!
Deyan Petrov

emmanuel · **Posted:** Tue Jan 06, 2004 1:40 pm

I'm not a OO programmer, but more an C(omponent)O programmer. So I sacrifise the OO paradygm and no business object call DAO. There always is a Service layer managing the process.

Your business model is fine according to relationship (kind of static one) but the finder methods are exernalized (dynamic one), I'm not so keen of my static/dynamic sentence :-)

deyanp · **Joined:** Fri Nov 21, 2003 11:22 am **Posts:** 16

I see now what you mean ... but this limits the amount of behaivour that can be put in the business objects, puts that behaivour in the business process/service layer classes and makes the interaction between these two a little bit awkward in my humble opinion.

What problems do you see with the scenario in which the persistable business objects also call DAO methods (mainly find(), but why not delete() as well)? I know that in this case if the object is sent remotely then that method cannot be executed any more, but I don't remote my persistent objects...

Best regards,
Deyan Petrov

snek · **Joined:** Thu Dec 11, 2003 6:21 am **Posts:** 8

I've also tried to think of the best approach for this, haven't figured out clear winner so far. At the moment I've got DAOs visible only to service layer, been satisfied with that so far, but I can see that one could quite easily end up with the so called 'anemic domain model'. I don't think though that this approach necessarily limits the amount behaviour you can put in domain objects, one just needs to patiently delegate work to domain objects.

deyanp · **Joined:** Fri Nov 21, 2003 11:22 am **Posts:** 16

Anemic domain model is exactly what I had in mind as well. It seems that I don't understand the big picture with the following ingredients - Fowler's Service Layer, Data Mappers and Domain Model. Questions like should the Domain Model call the Data Mappers or not, should the UI code call the Data Mappers directly or indirectly only via the Service Layer etc. seem to remain unaswered :(

stolley · **Posted:** Tue Jan 06, 2004 7:11 pm

I'm of the opinion that the questions you've asked don't need an absolute answer from the OO design gods. They need a decision. From you.

I can see (and have had :) multiple arguments for and against each of the patterns/structures you've talked about.

IMO, it all depends on the requirements of the thing that you're building.

That's pretty much the beauty of Hibernate. It's quite agnostic about these kinds of things, it can fit into any of these architectures with ease. Unlike a lot of other tools that really expect (if not require) some of these patterns to be used.

emmanuel · **Posted:** Wed Jan 07, 2004 3:19 am

deyanp wrote:

What problems do you see with the scenario in which the persistable business objects also call DAO methods (mainly find(), but why not delete() as well)?

I don't like DTOs and I use the detached object support of Hibernate. Thus business objects are used from UI to DAO. I don't want UI to call DAO, It may have been physicaly separated from the Service layer.
That's why my business objects no nothing of other layers

scesbron · **Joined:** Thu Sep 04, 2003 8:23 am **Posts:** 368

I really like the architecture emmanuel promotes but I have one question in this case. Where do you put unicity checks ? (for example Users have unique names) ?
You can't put them in the BOs because they know nothing about the mapping. You could then put them in the DAOs or in the process layer : any advice in which place to put them ?

Seb

michael · **Posted:** Fri Jan 16, 2004 12:21 pm

This was discussed some time ago allready, probably you can get something out of it: http://forum.hibernate.org/viewtopic.php?t=926778&highlight=unique

deyanp · **Joined:** Fri Nov 21, 2003 11:22 am **Posts:** 16

Hmm, I don't think the link is correct, as my question seems to be posted before the initial question in the thread you are referring to ...

deyanp · **Joined:** Fri Nov 21, 2003 11:22 am **Posts:** 16

Sorry, the above statement of mine seems to be wrong. Anyway, the thread about the Surrogate keys and business identity and the unique constraint checking does not have much to do with my question. I still don't know by the way what to do - either I am left(currently) with an anemic domain model, which doesn't help me much with all these long service layer method, or I start putting DAO calls in the business objects, which may not be the greatest idea in the world, who knows ...

Best regards,
Deyan Petrov