In this question we can see what ViewModel is: Pra does a ViewModel serve in ASP.NET MVC?
In this other question we can see what is DTO: What is a DTO?
But after all:
And there's still this one Using DTO and ViewModel in ASP.Net MVC project which I believe will not be duplicated
There in the question about DTO already has a good answer about what it is, except that < a href="https://en.stackoverflow.com/q/269089/101"> speak in fields as if they were attributes, but it is an error that 99.99% of people commit anyway:)
Let's forget a bit, and for an initial moment, the terminology used in the MVC to not confuse. Let's use the database terminology that is most common for people to understand.
The DTO is a way of organizing information in the application that comes from some source (s), usually a database, but may be another mechanism. We can understand the DTO as a view that you should already know about the database. Not that it is exactly this, but only to understand. The DTO takes data from the data source and assembles an easy-to-use object used by the application. In general, the DTO does a simple mapping and has no behavior. It is directly related to the data source, and can be used in various parts of the application for consumption only.
Generally when this type of object has behavior it becomes a pattern called Active Record . In some cases, Domain Object or other terminology is used with small subtle differences.
The DTO takes data from a source, probably a table from a database, and assembles a simple object. The RA allows you to have a logic of how the transfer will be made, and even business logic in it, although some authors indicate that there is already something else.
The DTO is a mechanism that can be used as part of the MVC model model, but is usually the AR that is used.
I do not like the question about DTO and viewmodel , I think it's confusing, probably wrong and follows a specific line of development I do not like. I'll ignore it.
Continuing in the database analogy the viewmodel , it looks like a view of a database that you already know, but only within your application. It is a template for the view of MVC. It is not a template for the database. Of course, it will have to communicate with the database model to get data, but the consumption is from the view of the MVC.
There are many simple cases that use an object via DTO, AR, DO, or whatever is suitable and simple, there is an easy relationship between that object and what it will use in the MVC view. But there are cases that are not so simple, you need object that will be consumed by view which is more complex that is composed of a subset of fields of those objects that bind to database or objects created by the application database or objects does not provide them, or even need data that is in several objects and it is difficult to use them separately, so compile (in the sense of join, not parse a source code :)) all this in an object that fits the view of the view of the MVC. That is, the viewmodel maps to the view of the MVC, while the model maps to the database.
Then the viewmodel is like a pre-set SELECT that generates an object ready and easy to use in view .
There is no relationship between the two. To find that the DTO is a viewmodel mechanism, in my conception, is wrong, but it is possible to make that analogy as a DTO between the MVC model and the MVC view.
If you do not have a view in the move, you do not have to use a viewmodel . And view can be of a design pattern known as MVC, MVP, or MVVM, and probably in RUI (which I'm still studying, and looks good), but can be views out of these known patterns, there are people who use an M (odel) V (iew) and a modelview can be useful even in such cases.
DTO is a primitive mechanism. Alone, in essence, it is useful in simple and straightforward applications. It is almost impossible to have a database application that does not have some form of DTO or its derivation, usually an AR, even if it does not look like it, since there are languages and frameworks that abstract this for you. The viewmodel is not required unless the mechanism that communicates with the view requires, which is common in the MVC frameworks out there, but it is more because of their deficiency.
Of course, the MVC's model is always an almost always more sophisticated form of DTO, often even more sophisticated than an AR. Often the model is represented by a repository, which is full of ARs and other mechanisms.
Use DTO to model the API of your system or backend, ie how the "external world" views the data model.
Use ViewModel to model the data exposed in the user interface (frontend).
When I started programming, I tried to weigh on a system as a whole, from the bank to the "little screen" as a single thing. I tried to reflect, as much as possible, the database on the screen and vice versa.
By skipping a decade, it is becoming increasingly clear that this does not work, for several reasons.
In a world of micro-services - or even in a large, well-organized system - it is important that every part of the gear works with a responsibility and a well-defined model. However, an endpoint may be quite different from how data is actually stored, if a database exists anyway. Implementation details do not matter to who uses the system.Therefore, the design of a modern system begins with the definition of the API. Developers can use any type of database and then, at the time of representing or receiving data from the outside world, the DTO standard is applied.
A complex system can aggregate data from several different sources and create a DTO as a return value. On the contrary, it receives a request with a body in JSON, for example, that some framework can automatically map to a DTO, and in the end the system can unlock that information and take different actions.
A very similar process happens in modern frontends, especially when we talk about Apps written in React.js, Android and many others.
Modern frontend is no longer a simple form based on a template technology, where you fill in some values and render for the user.
SPAs (Single Page Applications) and even Mobile Apps can consume information from a myriad of systems.
So it's common in modern designs to project the frontend completely independently from the backend (s) behind the system.
So you need to define View models. The data can come from different requests to different servers, from interactions with the user, the environment or browser, etc.
The two standards are used for the representation of data, but usually in completely different layers and isolated from a system or set of systems.
It's important to understand the concepts in practice, since technologies and frameworks can, in one way or another, take ownership of the concepts and confuse their application.
