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

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

注意:我只是指控制器"动作"方法,而不是构造函数,因为IoC的好处是显而易见的

Answer 1

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

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

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

对于您的DTO,他们不太可能有任何需要抽象的行为.作为事实上,这些对象应该不会有任何这样的行为.由于这个原因,将DTO隐藏在抽象背后是不合理的.

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

但是,对于您的DTO,您不太可能拥有具有相同属性集的其他DTO.正如其名称ITransactionQueryModel所暗示的,这是一组数据,它定义了"交易查询模式".换句话说,您将在ITransactionQueryModel抽象和实现之间进行一对一的映射.这几乎肯定没用.