What are the benefits of using DTOs?

[paulreicherdt]

Ok, the question is maybe a bit provocative, but I'll try to explain.

I just started to use the newest template and wondering - what are the benefits of separating DTOs and API contracts? By doing so, we create two mapping layers: from Entity to DTO, and from DTO to API contract. Why not just extract API contracts into a separate project and use them directly in the use cases? I mean, mostly (not always) the DTOs will mimic the API contracts structure and blow up the code base. And if you need to add new property, you will add it twice - in each layer.

You can go even further - if you extract the API requests/responses in separate project and let them implement MediatR interfaces you can just delegate the requests from endpoints to use cases and skip the mapping also on that side. So your endpoints will became a really this API layer.

I mean, I totally agree of separating API contracts and entities as those are different edges of the application. But why DTOs?

[ardalis]

I think you're talking about the DTOs in the UseCases project vs. the ones ultimately used by the API endpoints, right?

I've gone back and forth on this myself. One the one hand, a previous version of this template didn't even have a UseCases project, and so at that point the only types for a given thing were the entity (in Core) and the DTO(s) (in Web). But then when adding UseCases and MediatR messages the extra layer seemed to "deserve" its own set of types. It couldn't use the Web types, because the dependency direction, and it didn't make sense for it to return entities, either, so the simplest solution to the problem was to have each set of use cases define its own DTOs that made sense for it. Also, for a different UI, there might be different kinds of DTOs (ViewModels, other API endpoints, etc.) which might diverge from the UseCases ones. But, yeah, probably not that much, typically.

So, your idea of having a separate project makes sense to me. Just create a project for the API/UseCase contracts and put the DTOs like ContributorDTO as well as the MediatR Commands and Queries all into that project, and have both UseCases and Web depend on it. That would work, it would reduce mapping needs, but it would add another project. On the whole it's probably an improvement, but I do have to say that I already get a lot of pushback about how big and complex CA is in large part because it involves 3-4 projects. With the addition of Aspire that's 2 more and this would be yet another one and so imagine the outcry at having (shock!) seven non-test projects in the template (Core, Infra, UseCases, Web, Aspire, AspireServices, DTOsOrWhatever).

So, that's my current thinking. I'm not ruling out the change because I agree it would help out with the extra mapping, but the project count is a consideration. Want to make an issue proposing it (and maybe saying what name you'd like for said project) and we can see what others thing?

Thanks

[paulreicherdt]

Yes, I mean the DTOs in UseCases project and the ones in the API Endpoints. Sorry if I wasn't clear in this.

And thanks a lot for your explanation and the idea behind. Just one thing - non-test project count.. I don't really get it. I mean, usually I do not test classes that do not have any logic/behaviour. And the API contracts are.. well.. just contracts. But maybe I oversee something.

[paulreicherdt]

According the name of the project: "Sample.Api" or "Sample.Contracts" sounds like a best fit for me.
As an idea behind the name: it is then possible to share this project as a nuget package and with additional RestEase or whatever else you would have an entry point to your API, that you can inject and use with DI.

[ardalis]

I wasn't suggesting there would need to be another project for Contract tests. Merely that adding the contract project would add to the total number of projects, which currently is 6 but would be 7 with the additional one (not counting test projects at all).