15
In this question we can see that it is Viewmodel: What good is a Viewmodel in ASP.NET MVC?
In this other question we can see what DTO is: What is a DTO?
But after all:
And there’s still this one Use of DTO and Viewmodel in ASP.Net MVC project that I believe not to be duplicated
9
Back in the question about DTO has already got a good answer about what he is, except for the fact that speak in fields as if they were attributes, but it is a mistake that 99.99% of people make even :).
Let’s forget a little, and just for a moment, the terminology used in MVC not to confuse. Let’s use the database terminology that is most common people understand.
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 already know from the database. Not that it is exactly this, but just to understand. The DTO takes data from the data source and assembles an easy-to-use object used by the application. In general DTO makes a simple mapping and has no behavior. It has direct relationship to the data source, and can be used in various parts of the application only for consumption.
Usually when this type of object has behavior it happens to be a pattern called Active Record. In some cases Domain Object or other terminology is used with subtle differences.
DTO takes data from a source, probably a table from a database, and assembles a simple object. The AR allows 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.
DTO is a mechanism that can be used as part of the model of MVC, but it is usually the AR that is used.
I don’t like the question about DTO and view model, I think you’re confused, probably wrong and follow a specific line of development that I don’t like. I’ll ignore it.
Continuing in the analogy with the database view model, it’s like a view of a database you already know, but only within your application. It is a model for the view of MVC. It is not a model for the database. Of course he will have to communicate with the database model to get data, but the consumption is from view of the MVC.
There are many simple cases that using 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 view of MVC. But there are cases that are not so simple, you need to object that will be consumed by view that it is more complex that it is composed of a subset of fields of those objects that bind to the database, or fields created only on those objects because the application’s database or objects do not provide them, or it still needs data that is in several objects and it becomes complicated to use them separately, so compile (in the sense of joining, not analyzing a source code :) all this into an object that fits the demand of the view of the MVC. That is to say view model maps to the view of the MVC, while the model maps with the database.
Then the view model it’s like a SELECT pre-established that generates a ready-to-use object in the view.
There is no relationship between the two. Thinking that the DTO is a mechanism of view model, in my view, it is wrong, but it is possible to make this analogy as a DTO between the MVC model and the MVC view.
If you don’t have a view in play, there’s no point in using a view model. And view may be from a design pattern known as the MVC, MVP, or MVVM, and probably in RUI (which I’m still studying, and looks good), but may be views outside of these known patterns, there are people who use an M(Odel)V(iew) and a model view may be useful even in such cases.
DTO is a primitive mechanism. Alone, in its essence, it is useful in simple and direct 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 seem, since there are languages and frameworks that abstract it for you. The viewmodel is not necessary unless the mechanism that communicates with the view demand, which is common in frameworks MVC out there, but it’s mostly their disability.
For it is clear, the model of MVC is always a form, almost always more sophisticated, of DTO, in general even more sophisticated than an AR. Often the model is represented by a repository, which is full of Ars and other mechanisms.
I understood the difference, my vision (I may have understood something wrong) they are similar, but have totally different purposes. From what I understand, I was using it the right way, I just didn’t know why. I only have a small doubt (to clarify what is already clear), here you say O DTO pega os dados de uma fonte, provavelmente uma tabela it would be wrong to have a select "customized" that brings data from 2 or 3 tables and passed to a DTO with these fields or in this case it would be AR?
I do not know how to say with property, I think not, from what I understand, and if we are talking about the same thing, it is quiet, as long as the objweto result of this DTO is simple, IE, you|it is want the name of the client, but it is not in the base table for the DTO that only has a customer ID, I think it’s okay to take the name there to have on the object directly, because every application will need this, which is different from a view specific need it. But I’m not sure, I can research. 'Cause what I think is right is to do what you need, which name you’ll give is secondary, although I like to give the right name, help...
...better understand, better communicate.
I fully agree ;) Finally, without wanting to take time off, but already taking time off. I’m researching but I’m not finding about MVVP e RUI that you quoted. any article statement about?
The right was MVVM :D the RUI is new even has not much
kkk I suspected, but as it has so much stuff, it will rsrs. I will research more, then less ask here about. xD
6
Use DTO to model the API of your system or component (backend), i.e., how the "outside 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 in a system as a whole, from the bank to the "small screen" as one thing. I tried to reflect, as much as possible, the database on the screen and vice versa.
Skipping a decade, it becomes increasingly clear that this does not work, for various reasons.
In a world of micro-services - or even a large, well-organized system - it is important that every part of the gear works with a responsibility and a well-defined model. Meanwhile, a endpoint can be quite different from the way data is actually stored, if indeed a database exists. Implementation details don’t matter who uses the system.
Therefore, the design of a modern system starts with the definition of the API. Developers can use any type of database and then, when 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. Or the other way around: it receives a request with a JSON body, 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.
The modern frontend is no longer a simple form based on templates technology, where you fill in some values and render to the user.
The Spas (Single Page Applications) and even Mobile Apps can consume information from a myriad of systems.
Therefore, it is common in modern designs for you to design the frontend completely independently of the backend(s) behind the system.
Thus, you need to define models of the views or View Model. Data can come from different requests to different servers, user interactions, environment or browser, etc.
The two patterns are used for data representation, but usually in completely different and isolated layers of a system or set of systems.
It is important to understand the concepts in practice, since technologies and frameworks can, in one way or another, appropriate the concepts and confuse the application of them.
Browser other questions tagged terminology pattern-design viewmodel
You are not signed in. Login or sign up in order to post.
Good +1, I’ve been researching about, but for me it didn’t make much sense when using one and the other, I’ll wait for an answer here!
– Marconi
I had already searched for a while, but also had not understood. Usually I use Viewmodel in Web and DTO in Apis. but because I learned so, without a why(which is terrible)
– Barbetta