11

The code that sparked this question was a Service in my company's code base that contained four different DAO's. I didn't think much of this until I saw that this Service had become conflated with methods that belonged in a completely different Service. The reason for the creation of these unwarranted methods inside this Service was simply because that the needed DAO's were private members of this Service class.

Is this developer malpractice, or is it wrong in most cases to have more than one DAO per service class?

Note: I noticed that it seems reasonable to have more than one DAO per Service class as long as they are all contained within the same database. But having DAO's from multiple databases seems like it may cause issues.

stevebot
  • 23,275
  • 29
  • 119
  • 181

4 Answers4

14

I see nothing wrong having multiple DAOs per service class. When I first started doing web development many years ago, I had one service one DAO because that seemed to be the most logical and most straightforward approach. Then, I began seeing issues where there are similar APIs among DAOs serving different services. So, my "immature" solution was to promote these common APIs to some parent DAO to be inherited by these DAOs. When the project grows, it has come to a point where inheritance doesn't make any sense anymore, because I have situations where 80% of the children DAOs need that API but 20% don't, yet they still inherit from the same parent DAO because they share other similar APIs. You see the problem here? I mean, in Java, you can only inherit from one parent, so I ended up stuffing APIs that "might" be used by "majority" of the DAOs in the parent DAO, which completely violates the principle of inheritance in the first place.

Right now, all my DAO classes have specific responsibilities/tasks. It is okay for a DAO to call another DAO (for example, LoggingDAO is used by most DAO to log user actions). This way, instead of having one DAO that serves a specific service, the DAO provides a list of operations that may benefit the service. The Service will "use" whatever DAOs that will it to accomplish the task.

Hope this explanation helps.

limc
  • 39,366
  • 20
  • 100
  • 145
  • It does. In my case I think I was dealing with developer malpractice where people were shoving stuff into a Service based on it's DAO fields instead of based on the intent of the Service. – stevebot Jan 25 '11 at 01:58
  • Ahh, the problems with inheritance and subtype polymorphism ... all that aside, nice anecdote ;-) –  Jan 25 '11 at 01:59
  • In my opinion, a Service provides specific set of services to handle some user actions. These services may or may not utilize a DAO(s) to do the work. A DAO, on the other hand, provides the communication between Service and a database, yet it shouldn't know anything about what the user request is all about. If the developer mixes both of these together, then I don't see a point of having Services and DAOs because you can just combine them all together, which is awfully bad because you can't reuse whole lot of code. :) – limc Jan 25 '11 at 02:08
  • 1
    @pst: Inheritance used to be the kewlest thing for me, until things go out of control. The moral of the story is opt for composition instead of inheritance whenever possible, it makes unit testing so much easier too. :) – limc Jan 25 '11 at 02:10
  • 1
    One man's opinion on the internet: the EntityManager interface itself is a perfectly adequate abstraction for dealing with the persistence layer. The vast majority of 'DAOs' that are redundant with the already abstract EM are just clogging up lots of applications for nothing but an 'our application has good tiered architecture like the book says' warm-fuzzy :) – Affe Jan 25 '11 at 02:34
4

One to many is fine as long as it makes sense to break up the DAOs.

A couple of reasons I can think of where it makes sense to split a DAO:

  • Different Databases. If you are dealing with an account and a sales database, you might want to separate the DAO into a SalesDAO and a AccountingDAO. This will make maintence easier.
  • Reuse. You might have a few methods that could be reused across several places and splitting just those out will allow better reuse.
stevebot
  • 23,275
  • 29
  • 119
  • 181
jzd
  • 23,473
  • 9
  • 54
  • 76
1

At one company I worked at, they had a nice design where the service called a controller, and the controller could call another layer, which I can't remember, but that would then call the DAO.

So, they had an access level that could call multiple DAOs, in order to do a higher-order functions, so, if you want to do an order, it may require calling multiple tables, and perhaps several systems, so the controller would call the doOrder method.

This is a nice design as it keeps a good sense of separation and made unit testing simpler, as you can test each layer.

If your service is able to call multiple DAOs then unit testing may be harder, as you make the service layer more complicated.

So, when you are designing your layers, look at whether it makes sense to create new layers to simplify designs, which may uncover bugs or prevent bugs.

UPDATE:

The missing layer was the coordinator, and the rules were that each coordinator dealt with one DAO, and could do any transformations that were needed, but business logic was in the controller. So, a coordinator could talk to any other coordinator, to get information, and those coordinators would go to the DAO.

James Black
  • 41,583
  • 10
  • 86
  • 166
  • However, if you created a delegate class to call multiple DAOs, you essentially shifted the burden to this delegate. If testing a service with multiple DAO calls is hard, wouldn't this be equally hard to unit test the delegate class then? – limc Jan 25 '11 at 02:18
  • @limc - I realized the rest of the rules, and the name, which actually simpler. Spring was used, so you could swap in mock layers, so if you wanted to test the controller you would mock out the coordinator. – James Black Jan 25 '11 at 03:17
0

http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html

The amount on DAO's simply depends on the underlying sources !

Alexander Grosse
  • 287
  • 8
  • 23