7

When I first started using Hibernate I heard about all the joy of using a DAO layer. Initially it made sense for my problem: I was going to experiment with Hibernate and later experiment with NoSQL and/or XML for experience. It made sense at the time

Before I go any farther I want to say that my current DAO layer isn't a "true" dao layer. Its more of a bunch of data objects backed by interfaces and a "Controller" that generates new objects, queries, and cleans up when the application exits.

Now though I'm picking up Spring the DAO layer is starting to make less and less sense. NoSQL is neat and all, but I'm really starting to question if its worth it. I'm not even sure if my data is fit for NoSQL, it works quite well in a relational database. The horrible XML storage seems like a hurdle I'll cross later. Besides there's a huge of code I would need to support for other storage options: My custom "Controller" + a zillion Spring interfaces to implement + other stuff that I'm missing.

What's preventing me though from just ripping it out and merging the core and hibernate dao modules is that there's a few other projects that have a DAO layer (a real one) with only Spring and Hibernate. That means that they have all the interfaces, all the abstract classes, all the complexity with only those two frameworks. Since I'm just starting out in Spring+Hibernate world I'm hesitant to go against what others are doing with so little experience.

Question: Are their other advantages that I'm missing with having a DAO layer? And why would other projects have a DAO layer when their only using one database?

Improve this question
3
  • 2
    This question's kind of all over the place. First of all, ORMs such as Hibernate are considered a kind of DAO, or at least contain them - what else would you call a Session? Second, I can't figure out what NoSQL or XML storage has to do with any of that. Third, there's no such thing as a "DAO layer" (maybe you mean Data Access Layer or DAL?). And last, it's hard to tell whether you're asking if there's a point to DALs in general (which could refer to dozens of different things) or if you're just wondering if the specific one you're using is useful (in which case, we need more details).
    – Aaronaught
    Jul 31, 2011 at 18:43
  • @Aaronaught NoSQL and XML were going to be other storage options that would be using the DAO. IIRC, DAO was simply an abstract way to get info from the database. It can be hibernate but something more like getAllUsers(), getUser(id), and other stuff that you hide. And I'm more of wondering the point of DAO entirely instead of just my (albiet poor) system. I tried to clarify that at the end
    – TheLQ
    Jul 31, 2011 at 18:48
  • So you have methods like getAllUsers() and getUser(id) and you're asking if it's better to just pass the data connection around and have every consumer query it directly?
    – Aaronaught
    Jul 31, 2011 at 20:18

4 Answers 4

Reset to default
5

I'll try to tackle part of your question: why do I need a DAO layer if I never intend to swap databases?

As another respondent mentioned part of your goal when writing any class is the Single Responsibility Principle: a class should have only one reason to change. Simply put, you don't want to modify code without necessity, because doing so introduces risk. To minimize that risk, we try and avoid touching the implementation of a class for too many reasons. If I had to alter my class because the business rules changed, or because I decided to change how I mapped it into persistent storage, I would have two reasons to change my code. By removing one of those responsibilities, database mapping, I can avoid the risk of making an mistake that impacts the other, and the testing burden of checking both. I don't want to check my Db mappings, just because I change a business rule. You may also hear people talking about 'separation of concerns', that's another way of expressing this idea. A class that handles my logic for arranging shipping containers should not care about persistence.

It also comes into play when we think about unit testing. When I unit test my shipping container arrangement class, I don't want those tests to be coupled to other concerns, such as persistence. I want to be isolated from them. So I need to be easily able to test in isolation from them. If my class does not contain persistence logic, then I can easily test it in memory, without worrying about how it is persisted.

This driver produces an additional benefit: reasoning about our code. If we don't perform data-access at random points in our code, but through accessing to the DAO through an application service layer and then access to objects returned from that, I will not suddenly have unexpected I/O code running at some point during execution of business logic. It is also much easier to reason about our persistence code if it is not interspersed with business logic.

This makes it much easier to think about our code. We can follow domain logic without having our understanding polluted by access to persistent storage. This ability to reason about code easily is a key to productivity

The ultimate expression of many of these layering ideas is an hexagonal architecture.

You should be aware though that a domain model is not the ideal for all scenarios; particularly where you have no business logic. In that case a transaction script (one thing after another) might be the right solution. Some models, such as CQRS exist to try and gain the benefits of a domain model, without the costs for simple read access, for example for displaying a web page.

Improve this answer
1
  • Wow, that does make sense. I wish I could accept both your and Simon's answer, but since I can't I'm accepting yours for the good explanation. Thanks for the help
    – TheLQ
    Aug 1, 2011 at 17:05
7

They way you put it, the alternative to having a DAO layer is not having a DAO layer. Not having a DAO layer means that the code on the next higher level is responsible for handling low level persistence aspects, which contradicts the principle of single responsibility.

You don't necessarily have to use advanced frameworks like Hibernate and Spring. For small projects, or projects where it is quite convenient to think about data as being relational, it can be more of a hassle. However, not having any abstraction of the persistence aspect in a system would be a major design flaw.

Improve this answer
2
  • How is calling the database directly with lets say Hibernate criteria breaking simple point of responsibility? I wouldn't call that low level at all, that's pretty high up (not as high as DAO, but still). If some method is responsible for updating the db after say a form is submitted then it is the methods responsibility to load the object, change it, and be done
    – TheLQ
    Jul 31, 2011 at 18:30
  • @TheLQ: Let me clarify: I am not saying using an HSQL query violates the principle of single responsiblity. I am saying that a method grantDiscount() has no business in creating a Order object itself, instead it should use either Hibernate or customOrderDao.getById().
    – blubb
    Jul 31, 2011 at 18:39
1

It depends on what you're willing to do with your DAOs and what do you consider to be a DAO... Read Martin Fowler's AnemicDomainModel and you will understand what your model layer should/shouldn't do and, therefore, what a DAO should do.

For instance, in my opinion and based on my little experience, a DAO should handle transaction management(hibernate can do it for you, hence it implements DAOs behaviors for you), even if you're using only one database because you may never know when you would need to use a second one . A model (entity) should handle how and where it should be saved... Not the DAO... AnemicDomainModel problem should help you.

Improve this answer
0

The problem seems to stem from the fact that Hibernate and especially Spring are awfully complex beasts that do far more than most people could want, particularly in small/medium projects backed by a single data source.

And to solve that problem, just use a different, simpler, tool, instead of ditching the concept as a whole.

As for the benefits: flexibility, modularity and separation of concerns. The data is managed by code designed to do that and nothing else, and that allows you to, besides to change the data store, change the model/schema easily while providing the same API to code in the upper layers.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.