CODEWITHSUNDEEP
c#performancedomain-driven-design
Vinicius Gonçalves
Vinicius Gonçalves

Reputation: 2724

Entity VS Id as Parameter

I'm using DDD.

I have the following interfaces:

interface ICustomerRepository 
{
    void Disable(int customerId);
}

interface ICustomerService 
{
    void Disable(int customerId);
}

The application will work on a WebService.

I wonder, should I use id's as parameter or the entire Customer entity?

What are the pros and cons of each approach?

Upvotes: 1

Views: 148

Answers (3)

plalx
plalx

Reputation: 43718

Well, the fact is that this behavior shouldn't be on the repository. Behavior should be placed in entities.

However, your application service contract should probably be exempt of domain classes.

e.g.

//Application service (runs in a transaction)
public void Disable(int customerId) {
    var customer = this.customerRepository.FindById(customerId);
    customer.Disable(); //execute business logic
    this.customerRepository.Save(customer); //persist the state
}

Upvotes: 5

Eben Roux
Eben Roux

Reputation: 13246

Although the answer provided by plalx is probably the pure way to accomplish this I have also found that a full save may be overkill in some instances.

How about a mixture of the two:

interface ICustomerRepository 
{
    void SaveDisable(Customer customer);
}

interface ICustomerService 
{
    void Disable(int customerId);
}

Then the code could be:

public void Disable(int customerId) {
    var customer = _customerRepository.Get(customerId);
    customer.Disable();
    _customerRepository.SaveDisable(customer);
}

This will require one to be very careful about additional functionality since we are explicit about what is persisted.

Upvotes: 1

Zhr Saghaie
Zhr Saghaie

Reputation: 1071

Using CudtomerId is a better idea. Because when you pass the Customer entity (usually we use pass by value), it make a copy of it and work with it; Which is by default will be an empty entity.
So, I think your way is the best.

Upvotes: 0

Related Questions