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

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

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

---

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

作为抽象来隐藏行为。

为了允许一系列所有暴露相同数据成员的类型，就像它们是相同类型一样使用。

抽象允许我们截取，模拟或替换行为，而不必更改这些类型的消费者。 只有这种类型包含需要扩展或替换的行为时才需要。

就你的DTO而言，他们很可能不会有任何需要抽象的行为。 事实上，这些对象不应该有任何这样的行为。 由于这个原因，这使得在抽象背后隐藏DTO是不合理的。

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

然而，就您的DTO而言，您不太可能拥有其他具有相同属性的DTO。 正如ITransactionQueryModel所暗示的那样，这是一组定义“事务查询模型”的数据。 换句话说，您将在ITransactionQueryModel抽象和实现之间建立一对一的映射关系。 这几乎是无用的。

链接地址: http://www.djcxy.com/p/82255.html

上一篇: Should I hide DTOs and View Models behind interfaces or abstractions?

下一篇: How to write a unit test for the methods that change data?