Design Discussion around DAOs. Arguments (in favor) needed!

[etienno]

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.

[wexwarez]

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.

[etienno]

Thanks wexwarez, I will add this to my argument...

[constv]

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:

http://forum.springframework.org/showthread.php?t=64147

http://forum.springframework.org/showthread.php?t=64862

Good luck!

[shahnawazshahin]

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".

Hmm... not sure about this. I would say that in such cases if the Template Method pattern is used, then it is acceptable. The Template Method pattern is used where the business rules (or code that are less likely to change) are defined in an abstract class (like an abstract class Person). A concrete class that extends the abstract class would then contain code such as persistence.

If both business rules and data access logic are in the same class, then that is a definite no-no! See (and hope, at least ) if the Template Method is used.

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.

In contrast to the Template Method is the Strategy pattern, which is what you're promoting. The benefit of using the Strategy pattern is that it promotes separation of concerns (as you've mentioned) and supports object composition (meaning two or more DAOs can be used in conjunction) for flexibility.

In either case, I would support both Template Method and Strategy patterns. Strategy pattern is more preferred for large scale apps. You can Google for these patterns for more info.

Btw - does the solution use an application framework? Perhaps it is worth promoting this for the following reasons:

1. Promotes the use of best pratices.
2. Reuse time tested templates that are optimised, fully documented and developed by 1000s of contributers. No need to re-invent the wheel.
3. Improved productivity - developer can focus more on developing the business rules rather than the lower level or "plumbing" code.

All the best. At least this exercise can me made use for excellent learning .


Shah.

[al0]

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.

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.

[constv]

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...

[shahnawazshahin]

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.

That's spot on! Excellent.


Shah.

[al0]

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.

Regards,
Oleksandr

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...

[constv]

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.

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...

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.