CODEWITHSUNDEEP
javadesign-patternsservicedao
Preslav Rachev
Preslav Rachev

Reputation: 4003

On the proper usage of DAOs

Is DAO only reserved for the basic CRUD operations, or it could also contain some complex search logic?

Imagine the two entity classes Book and Author and the many-to-many relationship between them. At this point, a single DAO could be more than enough, as the basic CRUD operations for both entities are the same.

However, as the app gets more complex, new requirements appear, for example: 1. find the first book for a given author 2. find the books that an author has written during a period of time 3. find the books on a specific topic that a given author has written 4. .... etc

Where should all these go? Do I create now a separate DAO class for each entity, and put them there? Do they belong to the DAO layer at all?

I have this dilemma: where should the following methods go: findBooks(Author author) findBooks(Publisher publisher) both in the BookDAO, or one in AuthorDAO, the other PublisherDAO?

Or maybe I should think of a completely new abstraction, which is on top of DAOs and leaves them to basic CRUD ops - for example a SearchService, which lists all possible searches?

Upvotes: 3

Views: 838

Answers (3)

Cuga
Cuga

Reputation: 17904

Is DAO only reserved for the basic CRUD operations

No. Feel free to put all your data accessing logic in DAOs.

Don't confuse DAOs with DALs:

Upvotes: 3

Erhan Bagdemir
Erhan Bagdemir

Reputation: 5327

Where should all these go? Do I create now a separate DAO class for each entity, and put them there? Do they belong to the DAO layer at all?

see below.

I have this dilemma: where should the following methods go: findBooks(Author author) findBooks(Publisher publisher) both in the BookDAO, or one in AuthorDAO, the other PublisherDAO

It depends and i think it's not a question of enterprise software architecture, instead, OOD. As your logic is getting complicated, you must keep in mind to increase cohesion and reduce coupling between software compontents, and respectively extract a new class (Extact Class from Refactoring Catalog http://martinfowler.com/refactoring/catalog/extractClass.html) with these methods which is considered to be belong to the same business context, like AuthorDAO for all methods about Author functionality and Books for all Books calls, so on to make your code more readable, reusable, testable, maintable, ...

Or maybe I should think of a completely new abstraction, which is on top of DAOs and leaves them to basic CRUD ops - for example a SearchService, which lists all possible searches?

That abstraction exists in multitier model, is called business layer, if you mean business logic. You can associate your business logic with business objects. But the findXXX methods belong to your DAO which lies between persistence and business layer.

Upvotes: 1

manocha_ak
manocha_ak

Reputation: 902

Where should all these go? Do I create now a separate DAO class for each entity, and put them there? Do they belong to the DAO layer at all?

Definitely the job of and call for DAO (layer). What you have aove it is immaterial. The specific method should go to the DAO which it belongs to.

Or maybe I should think of a completely new abstraction, which is on top of DAOs and leaves them to basic CRUD ops - for example a SearchService, which lists all possible searches?

Two things here.

  1. Looks like you are using Hibernate or some ORM tool here. Hence you have proper objects I believe. And you can use those objects in DAO layer instead of Map or List or Primitives without any issue. Anyways, not deviating from DAO layer, you still can have DAO layer here. And do business rules validationd as you want.
  2. Looks You mean the AbstractDAO pattern (search/google for the same), again Hibernate and Spring do provide such things. Spring do provide a SearchService kind of tool (classes actually) for this too.

Upvotes: 1

Related Questions