Feb 4th, 2009, 05:12 AM
Design Discussion around DAOs. Arguments (in favor) needed!
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 / Service bean
|- 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.
Feb 4th, 2009, 11:41 AM
It sounds like your former developer is trying to find some compromise or middle ground with his old style of development.
I have certainly developed quicky projects with hibernate/spring where i put the dao calls within my service methods and it worked fine, but these were projects that I wasn't planning on maintaining for a long time or expanding upon.
I think the big thing to point out is that proper design becomes more and more important for bigger and bigger projects. Not only from a maintenance perspective, but if you are developing a large project then it implies that there is a good chance it will be around for a long time and if it is around for a long time there is a good chance that you may want to change a piece of it. This is why decoupling and separating these layers is important. In 2 years hibernate might be old news or maybe there will be a new version that is completely incompatible with the old and so it would be nice to have that layer separate.
Feb 5th, 2009, 03:35 AM
Thanks wexwarez, I will add this to my argument...
Feb 5th, 2009, 12:25 PM
1) Sounds like your architect is full of hot air... to say the least. Some obnoxious but insecure character who does not like to be challenged and is afraid to admit his own mistakes. He's been sitting in one place for too long, feeling quite comfortable - until some smarty-pants showed up... Prepare yourself for some serious political games and back-stabbing. :-(
2) Here are some similar discussions we've had here recently that you might find helpful:
Feb 6th, 2009, 09:27 AM
Feb 6th, 2009, 09:34 AM
I dare to say that his approach (as far as I understand it is similar to the Active Records pattern, but your description is too vague to be sure) has right to exist. I myself do not like it but amn't ready to declare it unsatisfactory.
Its main disadvantage is tight coupling to certain persistence technology, but if there are good reasons to believe that no technology migration would occur during project lifetime it may be tolerated.
Originally Posted by etienno
Feb 6th, 2009, 10:01 AM
Intellectual manageability is key!
I would like to add one note... The art of Software Engineering is not just about getting things to work. It is about representing a complex problem as a set of intellectually manageable sub-tasks. That is the only way to ensure the correctness of the design and the software itself in the first place - before the software is even written. (Dijkstra said this, not me.) It is also the only way to ensure the ease of future maintenance. Software that is not elegant or intellectually manageable is bad software, period.
The project etienno refers to has over 2000 classes. Regardless of what one considers large, the only way to effectively comprehend and manage 2000 classes is to intelligently organize them by functional domains, ensure clear separation of tiers and concerns within the domains. Mixing DAO methods inside entity classes, marrying the business tier to Hibernate, and hardwiring data access logic into the business logic is a sure way to end up with an unmanageable mess. And I would bet that it's exactly what that "architect" has on his hands today.
Good luck, etienno. Your head is in the right place...
Feb 6th, 2009, 10:05 AM
Feb 6th, 2009, 12:28 PM
If you collect all Dijkstra saying concerning software development process you would immediately notice that 90% of them is pure and obvious nonsense. Which in turn brings in question remaining 10 percents.
And it is of no big surprise as he was exceptionally talented mathematics and expert in algorithms theory, but never, ever was a practicing software developer. I'm even not sure that he has written at least one piece of code other then on paper.
As for system discussed - it is hard to say something definitive without seeing it, but dumb separation of business layer and persistence (if they were not separated from start) can bring 2500 or even 3000 classes in place of existing 2000. I'm seriously doubtful that it would made system more manageable.
The main question - is persistence-related code chaotically scattered all over the system or system accurately and carefully implement Active Record (or similar) pattern. As I already have written I'm not big fun of this pattern (have used it decades before its name was coined and was not very happy with it), but it is definitely viable and there are a lot of successful systems and even quite popular frameworks built around it (to name a few - Ruby on Rails , Castle).
So, if code is chaotic - it definitely need major overhaul, if it is clearly organized, even if its organization does not match your preferences, leave it as-is, unless not only architect, but whole development team is replaced.
Originally Posted by constv
Feb 6th, 2009, 12:59 PM
Oh, well... the fact that Dijkstra had a very dry sense of humor and liked to hyperbolize doesn't make his remarks nonsensical. It is just not wise, disrespectful, and irresponsible to make such a statement. Was Dijkstra wrong about the GOTO statement? Was he wrong stating that complexity is evil? is he wrong about the intellectual manageability? Is he wrong saying that testing is a great way to detect the existence of the bugs but does not prove their absence? Was he wrong stating that Basic sucked? We can go on all day...
Originally Posted by al0
Your above statement probably did not need a response, really... However it sets the tone for the rest of your post: it very much sounds like you post for the sake of stating a very strong opinion without adding much to the discussion. I don't think anyone will argue that if "improvements" result in even more complexity, they are not really improvements, and introducing them would be harmful. That doesn't mean that we should not always strive to keep the systems elegant and manageable. What prompted this thread, it seams to me, is that there is some complacent "architect"-bureaucrat sitting on a messy pile of code he helped to create in the course of 5 years. He resents fresh ideas, and makes it difficult for a new creative team member to contribute - mostly, for reasons of political nature. It is something many of us see on a daily basis, from project to project.