我应该将 DTO 和视图模型隐藏在接口或抽象后面吗？

Question

使用 IoC 可解析接口来指定 DTO 有什么价值？

举例：

private readonly IGetTransactionsQuery _query;
private readonly ICreateTransactionCommand _createCommand;

public TransactionsController(
    IGetTransactionsQuery query,
    ICreateTransactionCommand createCommand)
{
    _query = query;
    _createCommand = createCommand;
}

[EnableQuery]
public IQueryable<ITransactionQueryModel> Get()
{
    return _query.Execute();
}

public async Task<IHttpActionResult> Post(ICreateTransactionModel transaction)
{
    if (!ModelState.IsValid)
    {
        return BadRequest(ModelState);
    }
    await _createCommand.Execute(transaction);
    return Created(transaction);
}

在这里，我使用的是 ITransactionQueryModel 和 ICreateTransactionModel，而不是混凝土。这里有商业价值吗？哪些场景可以从这种方法中受益？我能想到一些，但想就用例场景

达成一些共识

注意：我只指控制器的“动作”方法，而不是构造函数，拥有 IoC 的好处是显而易见的

Answer 1

使用接口有两个常见的原因：

1. 作为抽象来隐藏行为。
2. 允许一组类型都公开相同的数据成员，就像它们是相同的类型一样使用。

抽象允许我们拦截、模拟或替换行为，而无需更改这些类型的消费者。仅当此类类型包含任何需要扩展或替换的行为时才需要这样做。

对于您的 DTO，它们不太可能有任何需要抽象的行为。事实上，这些对象应该不有任何这样的行为。由于这个原因，这使得将 DTO 隐藏在 抽象 后面是不合理的。

您的应用程序可能具有具有某些共同点的数据对象。例如，您可能决定应用程序中的所有实体都应具有Id 属性。您可以定义包含此Id 的IEntity 接口或Entity 基本类型。这允许您定义对基本类型或接口进行操作的方法，而不必为系统中的每个实体一遍又一遍地指定它们。

但是，对于您的 DTO，您不太可能拥有具有相同属性集的其他 DTO。正如名称ITransactionQueryModel 所暗示的那样，这是一组定义“事务查询模型”的数据。换句话说，您将在ITransactionQueryModel 抽象和实现之间进行一对一的映射。这几乎肯定没用。