Should the relationship between a Service and DAO be one to one or one to many?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.