实体 VS Id 作为参数答案

【问题标题】：Entity VS Id as Parameter实体 VS Id 作为参数
【发布时间】：2015-02-24 18:59:16
【问题描述】：

我正在使用 DDD。

我有以下接口：

interface ICustomerRepository 
{
    void Disable(int customerId);
}

interface ICustomerService 
{
    void Disable(int customerId);
}

应用程序将在 WebService 上运行。

我想知道，我应该使用 id 作为参数还是整个 Customer 实体？

每种方法的优缺点是什么？

【问题讨论】：

标签： c# performance domain-driven-design

【解决方案1】：

好吧，事实是这种行为不应该出现在存储库中。行为应该放在实体中。

但是，您的应用程序服务合同可能应该免除域类。

例如

//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】：

虽然 plalx 提供的答案可能是实现此目的的纯粹方法，但我也发现在某些情况下完全保存可能是矫枉过正。

两者的混合怎么样：

interface ICustomerRepository 
{
    void SaveDisable(Customer customer);
}

interface ICustomerService 
{
    void Disable(int customerId);
}

那么代码可以是：

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

这将要求我们对附加功能非常小心，因为我们对持久化的内容是明确的。

【讨论】：

有什么优势吗？
如果一个聚合需要不必要的数据访问，那么，是的，有一个优势；否则我不会这样做:)
这不是过早的优化吗？您是否在进行完整保存时遇到性能问题？我想这很好地取决于变更检测所采用的策略......
如果可以的话，我倾向于选择简单、维护代码更少的路线。所以我会尽可能保存完整的聚合。我不会认为它为时过早，因为在我做这样的事情之前，我通常会考虑 not 明确的影响。
好吧，在您的情况下，“需要维护的代码更少”是不正确的。您自己说过，“这将需要对附加功能非常小心，因为我们明确说明了持久化的内容。”。使用基于 ORM 的存储库，您不会关心在单个保存操作中添加的功能。你改变实体并保存它，就是这样。我需要维护的代码更少。

【解决方案3】：

使用 CudtomerId 是一个更好的主意。因为当您传递 Customer 实体时（通常我们使用按值传递），它会复制它并使用它；默认情况下将是一个空实体。
所以，我认为你的方式是最好的。

【讨论】：

Customer是一个引用类型（类），默认是引用传递。但我不认为这是一个问题。