-
Feb 4th, 2009, 05:12 AM
#1
Design Discussion around DAOs. Arguments (in favor) needed!
Hi,
I am a experienced Spring and Hibernate user. I have build many applications using this well used separation of concern :
View (jsf, struts, other)
|-view beans (session scoped)
------------------------
Business
|- Business / Service bean
------------------------
Persistence
|- Dao (services)
||- Entity mapping object
I am working on an already developed project (2000 classes) that do not have any DAO/persistence recommendation. And IMHO the persistence strategy of the this project is quite "unusual" and chaotic.
The current architect (working on this project since 5 years, and not a Spring user) do not believe that a DAO layer is necessary because:
1- "hibernate is a dao layer that can be use as-is inside the business".
2- "There's no use to have some business-specific dao methods inside a dao layer"
3- "Dao layer means: too many classes".
4- "we can insert dao methods inside the entities".
The arguments I am trying to push in favor for a DAO layer usage are:
1- Separation of concerns: a DAO layer is the only layer linked to the persistence process
2- Coherence: A dao layer is the only layer linked to the session factory, etc
3- Decoupling : for example, do not mix entities, dao and business layer
4- Life cycle and Transaction handling: the business layer has the transaction handling, etc.
Am I missing something here? Theses arguments have no effect. How could I make my point clearer?
Thanks A LOT for any advice.
E.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules