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?

回答1:

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
}

回答2:

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.

回答3:

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.

来源：https://stackoverflow.com/questions/28704015/entity-vs-id-as-parameter

标签

performance

domain-driven-design