CODEWITHSUNDEEP
javadesign-patternsjakarta-ee
Renato
Renato

Reputation: 13690

What is the better: to allow Services to access several DAOs or only other Services

I haven't found any questions addressing this specific issue. What is better: to allow Services (or facades) to access several DAOs (classes which talk to the database) or only other Services?

In other words, should I introduce inter-depencencies between different Service classes or is it better to make Service classes completely independent of each other by injecting more than one DAO (if necessary) to each Service class?

I found that both strategies will do the job, but I want to be consistent and make the application as modular and maintainable as possible.

Upvotes: 4

Views: 673

Answers (3)

GeorgeT
GeorgeT

Reputation: 51

It is not question of preference but it is question of encapsulation and make a DAO accessible through its relative service it is ok for services to call each other to access other service functionality and this could be seen in greater details in microservices it would be a messy code to let every service access any DAO it is just asking for trouble specially in big teams so in coding standard services should access only the related DAO for encapsulation and isolation of code.

Upvotes: 0

Affe
Affe

Reputation: 47954

There's some opinion in this to be sure, but a true "service" method should be an atomic unit of work. If they're creating a web of interdependency calling each other back forth and sideways, clearly the invocations aren't performing atomic tasks. I see nothing wrong with letting a "service" use whatever DAOs it needs. Creating a set of "service"-CRUD methods abstracting the DAO which is already a collection of CRUD methods which is itself probably abstracting away the abstraction that is JPA, you can see how that might be one too many levels of non-functional abstraction.

This approach does sometimes lead you to build shared "business beans" that are in the domain rather than the service, that multiple services share. This is fine.

(Can you tell I personally think JPA has made the entire idea of DAOs obsolete and we should just use EntityManager in the service? :) )

Upvotes: 3

madth3
madth3

Reputation: 7344

I feel that allowing or forbidding a service to call another service or more than one DAO is subjective. I try to avoid unnecesary code or odd couplings just to satisy some rule about layer-communication, and following basic OO principles of making simple, clear objects usually leads to a compromise.

  1. If a service B needs another functionality already comprised in a service A then it should call it. I try to reduce dependencies among services and usually end up defining a small set of "basic" services that can be called from other services.

  2. Creating a method in a service only to wrap a call to a DAO is pointless (in my opinion) and therefore I prefer to let services call as many DAOs as they need. Again, a service or a method with many DAOs indicates something that should be refactored or a data model that needs adjustment.

Upvotes: 3

Related Questions