CODEWITHSUNDEEP
asp.net-mvcmodel-view-controllerdto
RobVious
RobVious

Reputation: 12925

How to DTOs fit into the Repository+Service Pattern of MVC Applications?

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!

Upvotes: 3

Views: 2727

Answers (1)

Felipe Castro
Felipe Castro

Reputation: 1613

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.

Upvotes: 4

Related Questions