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

Testability of one immediate benefit you get out of it. Loose coupling and Dependency injection topics are worth of reading in this context. — Pankaj Kapare, Aug 17 '17 at 23:33
So, what you are actually asking is: what is [the advantage of Dependency Injection](https://stackoverflow.com/questions/14301389/why-does-one-use-dependency-injection) and [Dependency Inversion](https://en.wikipedia.org/wiki/Dependency_inversion_principle). — Steven, Aug 18 '17 at 06:05
@Steven, if I ask what is the benefit of owning a car on a one acre island, I am not asking about the benefit of owning a car. This is not a novice question, but thanks for the google search links..just in case I forget how to use it — I Stand With Russia, Aug 18 '17 at 14:36
Ah, okay, I think I get what you are asking (the title is very confusing). There is typically no value in creating abstractions for data objects. Abstractions are meant to _hide behavior_, but data objects (such as DTOs) don't have any behavior, so creating an abstraction for them is typically not useful, especially when there will only be one implementation. — Steven, Aug 18 '17 at 14:47
@Steven Please post this reply in answers, and i will mark it as "accepted" Also, feel free to edit the title for clarity — I Stand With Russia, Aug 18 '17 at 14:56

Steven · Accepted Answer · 2017-08-22T17:55:21.663

There are two common reasons to use interfaces:

As Abstraction to hide behavior.
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.

Steve, what if I want to have a generic controller, that takes as a parameter? Would that not be a good case for abstracting the DTO? — I Stand With Russia, Aug 22 '17 at 17:53
BTW, I own the first version of the DI in .net book, will buy yours. Much respect for authoring such important work! :) — I Stand With Russia, Aug 22 '17 at 17:55
@LastTribunal: That is still no reason to define an abstraction for your DTO, unless you use the interface as generic type constraint, in which case it falls in the second category. You should remember, abstractions should abstract over something. If there's nothing to abstract, abstractions are useless. — Steven, Aug 22 '17 at 17:58
@LastTribunal: Great to hear you want to buy the 2nd edition. Much appreciated. — Steven, Aug 22 '17 at 17:59

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

1 Answers1