Is exposing my DTO a view that is considered incorrect?

Question

This question has been around my head for the past weeks or months, and I really don't know what the best solution is.

Using the MVVM patter, we use View Models to display data in a view. For example, if I want to show the product information to the user, I will create some propositions inside the view model and fill them. Then, through the bindings, the view will be able to receive data from these properties. Something like that:

<StackPanel> <TextBlock Text="Prodcut Name:" FontWeight="Bold" /> <TextBlock Text="{Binding Path=ProductName}" /> <TextBlock Text="Price:" FontWeight="Bold"/> <TextBlock Text="{Binding Path=Price}"/> <TextBlock Text="Added Date:" FontWeight="Bold" /> <TextBlock Text="{Binding Path=Date}"/> </StackPanel> 

In the view model, I will get the data that I want to display. I will receive this data as a DTO product that will have the necessary properties in the view.

  this.productDTO = getData(); 

So my question is: can we bind directy from the view model to dto? View Model:

  private ProductDTO product; public string ProductName { get { return this.product.Name; } set { this.product.Name = value; } } public string Price { get { return this.product.Price; } set { this.product.Price = value; } } 

I have an idea that exposing the DTO is not very good. but if it saves me from having to map all the properties from the DTO to the view model.

Answer 1

If you don’t need to “format” your DTO to anchor your view, there is absolutely nothing wrong with exposing your DTO right in your opinion. You can always introduce a presentation model at some point in the future, if necessary.

You can also use templates such as mini-ViewModel (which I describe on my blog ) to add localized view models to form parts of your model.

By swapping the DTO in the view model, as you did, it adds code that doesn't do any good. This increases the size of your code base and the risk of errors.

KISS - Keep It Simple!

Answer 2

 private ProductDTO product; public string ProductName { get { return this.product.Name; } set { this.product.Name = value; } } 

The only problem I see is that when your dto Name property has changed, it is not just reflected in your user interface. so I would prefer this:

 public ProductDTO Product {...} <TextBlock Text="{Binding Path=Product.Name}" /> 

this of course requires your DTO to implement INotifyPropertyChanged

Answer 3

Technically, both methods are possible, but the DTO is usually not designed to be viewed and probably will not trigger any change notification events. You will have to either code this in the DTO, or put at risk potential user interface synchronization problems. I would advise you not to "enrich" your DTO in this way.

From an architectural point of view, a DTO object should be a cheap and small object. They do not require much effort to create or destroy, and you should not transfer them very far from your call stack, not to mention that they remain in memory for a very long time. In general, they are intended for data capsules, and they are intended only for transferring data from A to B. ViewModels, on the other hand, have behavior and implement a richer set of interfaces. The only thing they have with the DTO is that they also have data properties.

So, in your case, I would advise you not to save the DTO in your view model as a private participant, but to set the properties of the view model when retrieving the DTO, and then forget about the DTO again. As a general rule, do not let the DTO extend its life very far from the method when calling the service.