3

I'm about a month into MVC and from what I understand, a pretty good approach to app architecture is:

MVC <> Service <> Repository <> Core

Within MVC we have Views, and Controllers to populate viewModels for the controllers. My question is: Where exactly to Data Transfer Objects come in? I'm building a single-page web app and I'm trying to do it right from the beginning.

From the reading I've done, I should use DTOs to "flatten" the Model objects before passing them into the ViewModel. Do they act as a "only data that I need" object that gets passed from the service to the controller, at which point the viewModels are constructed? If so, is it generally true that each model definition (ie Sets, Cards, Users) should have corresponding DTO classes in the Core layer? Any clarifications here would be awesome, thank you for your time!

RobVious
  • 12,685
  • 25
  • 99
  • 181
  • Related: [DTO = ViewModel?](http://stackoverflow.com/questions/1982042/dto-viewmodel) – Tim M. Feb 28 '13 at 03:41
  • That answer describes DTO's and View Models as completely different, which is true in case of Silverlight/MVVM. In Asp.Net MVC, the concepts are actually quite similar. – Felipe Castro Feb 28 '13 at 03:50
  • @FelipeCastro - I think the answers to that question (especially the accepted answer) give a level of perspective. It's partially a semantic discussion, i.e. how the terms are defined and how people understand them and for the most part I agree that a DTO is quite similar to a ViewModel in ASP.Net MVC. This similarity doesn't make them interchangeable, but could easily eliminate the need for a DTO, namely, the Model can often be projected directly into the ViewModel. – Tim M. Feb 28 '13 at 06:03

1 Answers1

4

First of all, about this phrase: "a pretty good approach to app architecture is...": I don't believe there is a single good approach to all apps, and I would prefer always to use the simplest approach (i.e. fewer layers) that could solve your problem at hand.

When you say "Service", it appears to be a whole layer of web services, rather than just some domain service classes; in most cases I've seen with Asp.Net MVC, the controller itself can fulfill the role of a service, thus eliminating the need to add yet another layer. Of course there are exceptions, just be sure your reason to increase complexity is legitimate.

About DTO's and View models: DTO's, like you described, flatten the object model and return "only data that I need". DTO is a more generic term, usually used with web services where you don't know who is the consumer. Think of (Asp.Net MVC) View Models as a more specialized kind of DTO, that returns "only data that THE VIEW needs". Thus, if you don't need an extra layer of services, you also don't need an extra layer of DTO's, just use View Models to flatten the domain classes directly and return them from your controllers.

In fact, for very simple applications, even the separation of Models x ViewModels is overkill - it is possible to use a single Model layer to fulfill both roles, with the help of the ViewBag. I don't know your requirements, so I can't say which is better for you.

Finally, one comment: if you must build a single page application, Asp.Net MVC is not the best tool for the job. I'd recommend using Asp.Net Web Api (only services, no views) at the server and a client mvc framework, such as BackboneJs or AngularJs.

Felipe Castro
  • 1,623
  • 11
  • 10
  • +1 for "you don't need an extra layer of DTOs" and the mention of WebApi. I do think you should be careful with the "single Model layer" concept. Good, recent discussion on that here: http://stackoverflow.com/questions/15045445/mvc-using-domain-models-in-view-models/15045645#15045645 – Tim M. Feb 28 '13 at 06:06