DTO = ViewModel?

Question

I am using NHibernate to save domain objects. To keep things simple, I use the ASP.NET MVC project for both my presentation tier and my service tier.

I want to return domain objects in XML from my controller classes. After reading some posts here about stack overflow, I compile DTO. However, I also come across posts about ViewModel.

My question is: Are data transfer objects and ViewModels the same? Or is ViewModel a kind of DTO substructure?

Answer 1

The canonical definition of a DTO is a form of object data without any behavior.

ViewModels is a view model. ViewModels typically represent full or partial data from one or more objects (or DTOs) plus any additional elements specific to the behavior of the view (methods that can be performed by the view, properties that indicate how view elements are switched, etc.). You can look at the viewmodel as all the data to view plus behavior. ViewModels may or may not map business objects or DTOs to each other.

By the way, NHibernate projections come in handy if a particular viewing model requires a subset of the data from the stored object.

Answer 2

The ViewModel in ASP.NET MVC practice is the same as the DTO, however, the ViewModel in the MVVM template is different from the DTO because the ViewModel in MVVM has behavior, but the DTO does not.

Answer 3

DTO! = ViewModel

In MVVM, the ViewModel template is used to extract the Model from the view. You can use simple classes to represent the model.

Answer 4

DTO - data transfer objects in the same way as he says, containers for data transfer. They have no behavior, it's just a bunch of setters and getters. Some people make them immutable and simply create new ones when necessary, rather than updating existing ones. They must be serializable to allow cable transfers.

Typically, DTOs are used to send data from one level to another level across process boundaries, since remote service calls can be expensive, so all the necessary data is inserted into the DTO and transferred to the client in one piece (coarse-grained).

However, some people use the concept of screen-bound DTOs (nothing to do with crossing process boundaries). Again, they are filled with the required data (usually the data necessary for a particular screen and can be aggregation of data from different sources) and sent to the client.

http://blog.jpboodhoo.com/CommentView,guid,21fe23e7-e42c-48d8-8871-86e65bcc9a50.aspx

In simple cases, as already mentioned, this DTO can be used to bind to a view, but in more complex cases it will need to create a ViewModel and upload data from the DTO to the ViewModel, which obviously works more (when using MVVM).

So again, as already mentioned, DTO! = ViewModel

and

DTO and ViewModel have different goals in life

Answer 5

Firstly, the main difference is that the ViewModel may have behavior or methods that the DTO should not do !!!

Secondly, using DTO as a ViewModel in ASP.NET MVC makes your application closely related to DTO, and this is exactly the opposite goal of using DTO. If you do, what's the difference using your domain model or DTO, is it harder to get an anti-template?

Also ViewModel in ASP.NET can use DataAnnotations for validation.

The same DTO can have different ViewModel mappings, and One ViewModel can consist of different DTOs (always with object mappings, not composers). because I think it’s even worse if you have a ViewModel that contains a DTO, we will have the same problem.

At the presentation level, imagine that DTO is a contract, and you will get an object that you should consider unfamiliar to your application, and you will not have any control over it (even if you have a service, dto and your presentation levels).

Finally, if you make this clean separation, developers can easily work together. The person who develops ViewModels, Views, and Controllers does not have to worry about the DTO service or implementation layer, because he will make a comparison when other developers finish their implementation ... He can even use the Mocking tool or manual mockery to fill the presentation layer with data for testing.

Answer 6

For some simple views, I will use my DTO as my models, but as views become more complex, I will create ViewModels.

For me, this is a balance between speed (using DTO, as I already have) and flexibility (creating ViewModels means more separation of problems).

Answer 7

If you use the DTO as a ViewModel, it means that you are very dependent on the DTO for some reason, you are changing the DTO, then this can affect the ViewModel.

It is better to use DTO and convert to viewmodel.