4

Let's say I have one database with two tables: companies and employees. Should I create companyDAO and employeeDAO If I select, update, add and remove from those two tables?

Or I should create one DAO in which I'll write methods for CRUD operations for every table in the database?

THE Waterfall
  • 645
  • 6
  • 17

5 Answers5

4

Creating one DAO for the entire database doesn't scale well. The more database tables you add the larger it gets. In industry you'll almost always see a one to one DAO to table relationship. As always there are exceptions and caveats.

Robert Garrett
  • 96
  • 10
  • 2
    Agreed. But I'd prefer to say you have one DAO per _entity_ or per _class_, rather than per _table_, as you typically don't have DAOs for the relation tables in many-to-many relationships. Moreover, it is more suitable for the object-oriented approach. – Jan B. May 25 '18 at 16:04
3

As the name suggest, DAO that stands for Data Access Object, is an entity to access ONE object or class. It is standard software engineering and enterprise industry (esp. in Java) best practices to have one DAO for each business entity.

If you are reusing similar behavior and data among several DAOs it is often handy to create a base DAO and extends it by other DAOs.

Also read https://en.wikipedia.org/wiki/Data_access_object

royalghost
  • 2,773
  • 5
  • 23
  • 29
1

Yes, it makes sense to have separate DAOs for most of the entities.

Often times you'll work with generified DAOs, i.e. you have an abstract super class. In a simplified example, it could look like this:

class BaseDAO<T extends Entity>

that provide a bunch of useful methods to find, remove or update the entities. When defining a subclass of that BaseDAO for each Entity, e.g.

class EmployeeDAO extends BaseDAO<Employee>

you make sure that all your DAOs return the correct type for the methods which you only have to implement in your BaseDAO. So, the findAll() method in your EmployeeDAO will return List<Employee>.

Moreover you can implement methods for customized operations for certain entities, e.g. findEmployeesWithSalaryAbove(long) in the respective class. You don't want these to clutter a single DAO.

Jan B.
  • 6,030
  • 5
  • 32
  • 53
  • So in general, it would look like I have one abstract superclass BaseDAO with common methods for every entity and other subclass DAOs which would extend BaseDAO with their own specific methods? – THE Waterfall May 25 '18 at 16:40
  • Yes, exactly! There are various articles on the internet that may be helpful for the general approach, e.g. https://dzone.com/articles/dao-layer-generics-rescue Lot of frameworks already provide solutions with prepared AbstractDaos like Spring etc. – Jan B. May 25 '18 at 17:32
0

You should create one DAO for single Hibernate Model (in most cases). Model can be a representation of all table columns, part of table columns, or a composition of multiple table columns. It all depends on your needs.

When you want to do this (have single DAO mapping entity to multiple tables), when you want to separate hibernate model from business model.

Beri
  • 11,470
  • 4
  • 35
  • 57
0

Adding to the other answers, you can use a DAO factory class that gives you access to all of the DAOs you need for one individual implementation class. This keeps code clean as you don't have to pass numerous DAOs to the constructor of your class. You only need to inject the single DAO factory.

public class YourClassDAOFactoryImpl implements YourClassDAOFactory {
  @Override
  public CompanyDAO getCompanyDAO() {
    return new CompanyDAO();
  }

  @Override
  public EmployeeDAO getEmployeeDAO() {
    return new EmployeeDAO();  
  }
}
Tom111989
  • 35
  • 4