From the Model to the DTO to the ViewModel seems just too much

Question

I know a DTO is not a ViewModel. The usage can be the same when its misused but the origion purpose is different.

I return domain entities from my Repository to the Service. In my Service I have to reshape the entities due to the needs of my tabular view.

Now I have a conflict. Normally my service would return a DTO with the data BUT in this case the data is reshaped due to the needs of the presentation layer. Someone could say then the DTO is a ViewModel but I do not want to return a viewmodel from my service.

In this case the DTO is a ViewModel, ok the behavior is missing, but what if there is no further behavior.

Something is wrong here.

please expand on the question. This seems more like an architectural choice than actually being stumped... — Dave Alperovich, Feb 16 '13 at 16:17
@Dave yes its an arch. choice. What exactly do you not understand else I have no idea where I should expand. Please explain :) — Elisabeth, Feb 16 '13 at 17:19
I'm lost b/c going by your question, I feel like answering "Just use a presentation Model. Transfer data from your DTO to PLM, and back." But seems like you already know that. — Dave Alperovich, Feb 16 '13 at 17:33
Have a look here http://stackoverflow.com/a/10909409/1241400 — Matija Grcic, Feb 16 '13 at 18:35
Thanks plurby but that did not help in my case. Dave forgot what I said, I will just straight use the DTO and then map to ViewModel and I will see how it works if everything evolves. — Elisabeth, Feb 16 '13 at 21:13

score 1 · Accepted Answer · answered Feb 16 '13 at 18:27

It can feel like too much, but don't overlook that it may be just right now that there is an exact match on what you're wanting to generate at the service and UI level. There is nothing inherently wrong about having those two pieces separate but nearly identical.

Often a ViewModel will be further extended to support computed fields, options for UI selection etc. It will always be easier to extend that distinct object down the road without having to blow up your service (and anyone who's taken a dependency on it).

On the other hand, I really like to follow YAGNI. So, if you honestly believe there is no way this object is likely to grow, recycling something isn't always terrible. (More context would definitely help to make this call).

Finally, don't spend so much time on the academics of it. You seem to have a pretty good handle on what you're trying to accomplish, and the only good code is shipped code. Write tests, separate what you can, but get the code out the door. I've seen projects fail because of over-engineering.

Cheers.

I went with your answer also its not best for me atm because I have more questions... http://stackoverflow.com/questions/15097732/a-viewmodel-has-a-behavior-methods-compared-to-a-dto-but — Elisabeth, Feb 26 '13 at 19:36

score 0 · Answer 2 · answered Feb 17 '13 at 14:04

I feel your pain. I don't use the "repository" pattern however my service layer returns DTO's to my controller which then at some point populate most or at least some of the properties in my ViewModel. This seems like overkill at times and always raises the question "is this the best way to do things" The answer, from what I have been told and from what I have researched is "YES".

score 0 · Answer 3 · answered Feb 17 '13 at 17:47

I would suggest you have a PresentationService in your controller and that object is what is responsible for returning your view model. Your presentation service then uses domain services, data services, or your repositories, or whatever else you need in order to aggregate the data to your view model.

It's ok for you to use a DTO as a view model if the shape coming from the database is what you want but if it's not and you have some other kind of data projection then a presentation service is a good practice.

From the Model to the DTO to the ViewModel seems just too much

3 Answers3