CODEWITHSUNDEEP
javarepositorydomain-driven-designdao
Manolo
Manolo

Reputation: 1676

should dao (or perhaps repository) take id's or entities as arguments

In our code base we make extensive use of DAOs. In essence a layer that exposes a low level read/write api and where each DAO maps to a table in the database.

My question is should the dao's update methods take entity id's or entity references as arguments if we have different kinds of updates on an entity.

For example, say we have customers and adressess. We could have

customer.address = newAddress;
customerDao.updateCustomerAddress(customer);

or we could have

customerDao.updateCustomerAddress(customer.getId(), newAddress);

Which approach would you say is better?

The latter is more convenient since if we have the entity we always have the id, so it will always work. The converse is not always the case though, but would have to be preceded with getting the entity before performing the update.

Upvotes: 0

Views: 186

Answers (2)

Constantin Galbenu
Constantin Galbenu

Reputation: 17683

In DDD we have Aggregates and Repositories. Aggregates ensure that the business invariants hold and Repositories handle the persistence.

I recommend that Aggregates should be pure, with no dependencies to any infrastructure code; that is, Aggregates should not know anything about persistence.

Also, you should use the Ubiquitous language in your domain code. That being said, your code should look like this (in the application layer):

customer = customerRepository.loadById(customerId); customer.changeAddress(address); customerRepository.save(customer);

Upvotes: 3

cmoetzing
cmoetzing

Reputation: 792

I assume your question is

Which approach of the two is better?

I would prefer the second approach. It states clearly what will be done. The update object will be freshly loaded and it is absolutely clear that only the address will be updated. The first approach leaves room for doubt. What happens if customer.name has a new value aswell? Will it also be update?

Upvotes: -1

Related Questions