Should I hide DTOs and View Models behind interfaces or abstractions?

Question

In there any value in using IoC resolvable interfaces to specify DTOs?

Fer example:

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);
}

Here, I am using ITransactionQueryModel and ICreateTransactionModel, instead of the concretions. Is there any business value here? What scenarios can benefit from this approach? I can think of a few, but wanted to get some consensus of use case scenarios

Note: I am only referring to the controller "action" methods, not the Constructor, for which the benefit of having IoC is obvious

Answer 1

There are two common reasons to use interfaces:

1. As Abstraction to hide behavior .
2. To allow a set of types that all expose the same data members, to be used as if they are the same type.

Abstractions allow us to Intercept, Mock or replace behavior without having to change the consumers of these types. This is only needed if such type contains any behavior that needs to be extended or replaced.

In the case of your DTOs, it is very unlikely that they would have any behavior that needs to be abstracted. As a matter of fact, those objects should not have any of such behavior. This makes it unreasonable to hide a DTO behind an Abstraction for this reason.

Your application might have data objects that have certain things in common. For instance, you might decide that all entities in your application should have an Id property. You can define an IEntity interface or Entity base type that contains this Id . This allows you to define methods that operate on the base type or interface, instead of having to specify them over and over again for each of the entities in your system.

In the case of your DTOs however, it is unlikely that you will have other DTOs that have the same set of properties. As the name ITransactionQueryModel implies, this is a set of data that defines the 'transaction query model'. In other words, you will have a one-to-one mapping between the ITransactionQueryModel abstraction and the implementation. This is almost certainly useless.