Question

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

Fer示例：

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，而不是结核。这里有商业价值吗？哪种方案可以从这种方法中受益？我可以想到一些，但希望得到一些用例场景

的共识

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

Answer 1

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

抽象隐藏行为。
允许一组所有公开相同数据成员的类型，就好像它们是相同的类型一样。

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

对于您的DTO，他们不太可能有任何需要抽象的行为。事实上，那些对象应不具有任何此类行为。因此，将DTO隐藏在抽象之后是不合理的。

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

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

我应该在界面或抽象背后隐藏DTO和View Models吗？

1 个答案: