Can the data transfer object`s data match the UI needs

Question

The data transfer object holds data from multiple business objects sent to the client.

But should/could this data and its structure be extra setup for the client to fit its binding needs?

Or should I extra create a ViewModel for this?

Its a small application so I am hesitating about too much overarchitecting and the dto`s would be 90% the same as the viewmodels...

The DTO`s would be transfered from a restful server to a javascript client not more.

Answer 1

I think the thing to consider is what differences exist between the VM and DTO. A while back, I was attempting to create C# view models which implemented, derived from, or contained the DTO contract plus all the view centric stuff such as select list options and filter properties. I found this to be cumbersome, fragile and WET (as opposed to DRY ;).

I've since moved to a pattern of defining my view models in JavaScript and allowing the DTO objects to contain only the properties necessary to satisfy the contract expectations of the service layer. I pull data down using ajax. The data is typically passed into the view in the format it was received from the service. I then update my data-bound, observable knockout view models. So far, this pattern has been really productive for me.

With regard to input validation, so long as we're talking about validation attributes, I think it's perfectly fine that you have validation attributes defined on your DTO. After all, your API controller has a ModelState for a reason. Unfortunately, there's not a really good method to translate that validation into your client-bound views. As such, I've been leaning on knockout validation more than MVC's validation. I'm holding on to hope, however, that there is a better solution validation solution out there!

Answer 2

I like to consider the representations that I retrieve as wire representations of my ViewModel. In many cases there is no need to make a distinction between ViewModel and DTO.