Best practices for DAO

[mdalsey]

I'm new with Spring, so sorry if this is a stupid question or has been covered before or if this is the wrong forum. I'm trying to learn Spring & Hibernate and am using the petclinic as an example.

If I wanted to delete an object based on an id, which of the following would be correct:

#1 - The dao delete method accepts an id, calls the dao load method to get the object reference and then deletes.

#2 - The dao delete method accepts an object reference and the load and the delete are called separately from another layer.

Thanks very much for any feedback.

[chenrici]

I suggest a variation of the second approach.
I would seperate DAO and Domain Layer.
And pass the Domain Object loaded otherwhere to delete to the DAO Layer.

Christoph

[mdalsey]

Thanks very much for the reply. I have a follow up question.

Let's say I did decide for some reason to call a DAO method from within another DAO method. Is this a poor practice? If both methods were configured for transaction propagation, will I end up just one overall transaction, or will this situation result in some sort of ugly transactional mess? I guess overall I'm wondering if it's OK to call getHibernateTemplate() multiple times within the same DAO method or if I should try to write my DAO methods to do just one specific thing.

Sorry again if these are dumb questions and thanks for any feedback!

[chenrici]

Myself i'm quite new to Spring and have'nt used Hibernate at all, so i don't how valuable my suggestions really are for you ;-)
I don't see any reason, why you should'nt be able use another DAO within a DAO , given specific requirements. Apart from that , i would suggest to have Classes of the Domain Layer as Targets for the Transactional Proxies and not the DAO's.
Christoph

[khote]

I agree with chenrici completey. Separate your domain objects from your DAOs. You may discover at some future date that you need a different kind of DAO to retrieve a domain object

Let's say I did decide for some reason to call a DAO method from within another DAO method. Is this a poor practice? If both methods were configured for transaction propagation, will I end up just one overall transaction, or will this situation result in some sort of ugly transactional mess? I guess overall I'm wondering if it's OK to call getHibernateTemplate() multiple times within the same DAO method or if I should try to write my DAO methods to do just one specific thing.

Sorry again if these are dumb questions and thanks for any feedback!

Personally I prefer having business objects - some kind of facade pattern - to handle situations which require mutiple DAOs.

If you design your object trees right (with the right kind of cascades and ownership) Hibernate can handle alot of the deletions under the table, so to speak.

As far as transactions - are you designing a web application or some kind of stand-alone application?

For webapp, investigate the OpenSessionInView interceptor. Your DAOs can join an existing transaction when using the HibernateTemplate, they don't have to be directly involved in the transaction management themselves. I like to put the control of such things above my DAO layer, more in the layer that's requesting dao services or even higher.

[mdalsey]

Thanks for the advice and for taking the time to respond.

[Colin Sampaleanu]

Thanks very much for the reply. I have a follow up question.

Let's say I did decide for some reason to call a DAO method from within another DAO method. Is this a poor practice? If both methods were configured for transaction propagation, will I end up just one overall transaction, or will this situation result in some sort of ugly transactional mess? I guess overall I'm wondering if it's OK to call getHibernateTemplate() multiple times within the same DAO method or if I should try to write my DAO methods to do just one specific thing.

Sorry again if these are dumb questions and thanks for any feedback!

Personally, I would normally wrap my service layer interface methods transactionally, not the DAOs used by them.

But in either case, when you are in a transaction, and call into another object that is transactionally wrapped (by the same transaction manager), you will just take part in that existing transaction.

[mdalsey]

Colin -

Thanks for the information and for taking the time to answer my question. This is very helpful.

[Keith Donald]

I've attached a thread discussed at Matt Raible's www.raibledesigns.com regarding the use of structuring a middle-tier layer (specifically, one where I recommending starting with a single service layer and extracting out a DAO only if you need to.)
-------

Keith said...
- Hey matt - collapsing your dao layer into your biz layer would save you 3 to 4 classes per entity, and probably wouldn't get you slapped (I wouldn't slap you anyway.) Of course, you could also scrap the tests if all you're doing is CRUDing by delegating to Hibernate, but I didn't say that. ;-)

Todd said...
> I was intrigued by Keith's comment about accessing DAO's directly in the business logic. My feeling is that a manager layer is only occasionally necessary when it adds real value/functionality on-top of the DAO layer. Otherwise it's just an unnecessary pass-thru layer sending the model objects right through to the DAO layer without doing anything. Matt, I'm curious what your thoughts and experiences have been regarding when to use a manager layer?

Matt said....
>> The main reason for the Manager layer is to wrap its methods with transactions so that multiple calls to DAOs (in a Manager's method) will take part in the same transaction. I've seen some folks get around this and wrap their Actions (i.e. WebWork) with transactions.

Keith said again...
- Collapsing DAO into biz, keeping transaction demarcation at the biz layer is a viable design worth considering with apps with little to no business logic (CRUDers). Also, no one says you have to create a new DAO implementation for each entity--a single facade for the entire application is fine for a small app. Spring's Petclinic is a good example of this. I generally start with a single biz layer and then extract out a lower-level DAO layer only if I need it, for two reasons: to demarcate transactions for biz operations that span multiple DAO operations (what Matt said), AND to decouple my biz logic workflow from my data access technology (which simply not a concern for apps with little biz logic since the biz logic IS the persistence logic). Note with a single biz layer you can still get transaction demarcation for biz operations spanning multiple DAO calls: just have the public interface implementation (which executes transactionally) delegate to private DAO methods within the biz implementation. Don't introduce more layers than you have to, that's what I say (start simple and scale up by refactoring only if you see the need.)

Todd said again...
>>Isn't one of the goals of AOP in Spring to use interceptors to demarcate transactions (rather than having to create a facade like a Manager) to do transaction demarcation? Or is that approach sometimes too simplistic in practice?

Keith won't shut up...
-Spring has a "TransactionProxyFactoryBean" which at runtime can dynamically proxy any POJO to make it execute in the context of a transaction managed by JTA or by a single JDBC resource, completely transparently to callers. It does this by applying a Transaction Interceptor (around advice) that intercepts main flow of execution, typically beginning a transaction before method execution and committing or rolling it back after method execution. The TransactionProxyFactoryBean also accepts fine grained policies about which methods should be made transactional on your POJO object (and which ones should be excluded), which types of Exceptions should/should not trigger a rollback, and the isolation levels and propogation behaivior to use. Now, with that said, yes, it is possible to demarcate transactions at the web-tier, for example on your controllers. Spring can proxy any java interface (using Dynamic Proxies) or class (using cglib). However, I would not recommend this. It's much cleaner to have a well-defined business layer that captures the business requirements of your application, and demarcate transactions there. I think this central to any application: the web layer (and any other presentation layer like Swing) should be kept thin, delegating to the biz layer for the execution of domain-specific use cases. There are many advantages for doing this: 1. It's clear WHAT your application does (through a well-defined, descriptive business contract), 2. biz and persistence logic is fully decoupled from presentation, 3. because of #2, biz/persistence logic can be tested independently of presentation concerns, and 4. middle-tier people and presenation-people are often different people in practice, and the two layers can be developed independently. As I alluded to previously, I see less value in automating the testing of your controllers when the meat of your application is centralized behind a well-defined business. I see more costs than benefits in defining an additional DAO layer when all your application is is a data entry system (CRUDer).

HTH! :-)

[stutchbury]

Keith said again...
- Collapsing DAO into biz, keeping transaction demarcation at the biz layer is a viable design worth considering with apps with little to no business logic (CRUDers).

I would suggest this (the issue of domain object logic/validation) would be the main influence your decision. I prefer to see the DAO doing only system integrity checks (or delegating that to the database). By implication, business validation is therefore performed in the service layer.