using ViewModels instead DTOs about cleanarchitecture HOT 6 CLOSED

Sorry for the delayed response, I am trying hard to catch-up.

It is somewhat of a convention that I am following. Queries return a single VM composed of DTOs. I want the VM to be associated with a single view. VMs should not be shared across views. DTOs could potentially be shared but I would try to minimise sharing where possible. This is because I want to avoid creating conditional logic for separate (but closely matched) use cases and I want to avoid breaking changes (change one query, break another).

@ardalis had a couple of great weekly dev tips on this topic:

1. https://www.weeklydevtips.com/episodes/008
2. https://www.weeklydevtips.com/episodes/009

I also like the Request / Response approach, e.g. GetCustomersRequest and GetCustomersResponse. It is probably a better representation of the use cases and results and I think it would be nicer when writing client code.

Open for suggestions. 😀

from cleanarchitecture.

I agree with the previous comments. They are, in essence, just terms and there are many valid ones as shown above. Personally, since we are using the Request/Response pattern, I would call them *Request for the input and *Response for the output.

from cleanarchitecture.

Those are just terms in this context, I guess. The *Vm ones are more like containers for complex responses. *Dto is a single entity. You may also always use the Representation suffix.

Nonetheless I agree with Vm being a bit confusing. Can't think of a better name like Container for now tho.

from cleanarchitecture.

I just use the term Model usually

from cleanarchitecture.

As I know, by DDD we should return DTOs from application layer.

DDD has no correlation to the Application layer. It doesn't even know it exists.

VM vs DTO is an Application layer concern only. It doesn't matter which type you choose, it just depends on your use case. This solution comes with examples for both.

from cleanarchitecture.

As I know, by DDD we should return DTOs from application layer.

DDD has no correlation to the Application layer. It doesn't even know it exists.

VM vs DTO is an Application layer concern only. It doesn't matter which type you choose, it just depends on your use case. This solution comes with examples for both.

Actually, DDD do have a notion of Application Layer. Taken from Evans' Domain Driven Design book

Application Layer: Defines the jobs the software is supposed to do and directs the expressive domain objects to work out problems. The tasks this layer is responsible for are meaningful to the business or necessary for interaction with the application layers of other systems. This layer is kept thin. It does not contain business rules or knowledge, but only coordinates tasks and delegates work to collaborations of domain objects in the next layer down. It does not have state reflecting the business situation, but it can have state that reflects the progress of a task for the user or the program.

But it is true that the domain layer should have no notion of the application layer since the dependency flow inward.

To be fair, DTO is, in essence, an umbrella term that defines an object made to transport data in between process/layer.

from cleanarchitecture.