MVC thin controller architecture

Question

lately I've been toying with the idea of placing ViewModels in a separate project and populating them in repositories, then handing them to the controller. This could make for really thin controllers.

What is this pattern called?

Answer 1

Hexagonal Architecture has this notion of Adapters, in this case you're adapting from business objects to presentation objects.

However :

• If you mean repositories as in persistence layer repositories, it's typically not their responsibility to populate presentation-specific data structures. The persistence layer shouldn't know about the UI.

• "Thin controller" doesn't mean you have to place the ViewModels or ViewModel population logic in a separate project. Besides, just because a controller shouldn't contain this logic doesn't mean it can't invoke it. Your controller can call an Adapter object from the same MVC project to convert from whatever it receives to ViewModels, or you could just do the conversion in the ViewModel's constructor.

Answer 2

While @guillauem31's answer is usefull, I think it was missing a bit, and a bit misleading

In short, an adapter is

Adapter
The ‘Design Patterns’ book contains a description of the generic ‘Adapter’ pattern:
 “Convert the interface of a class into another interace clients expect.”

In my mind, I'd like to place an adapter between the controller and repository.

He usefully suggests that the adapter can be in a constructor of the viewmodel. I'm not sure I like this, but it seems okay.

I'd really like to keep my models as simple class objects if possible.

So I'd be equally okay with populating the viewmodels in a service layer.

and I guess thats where this question comes in... Fat model / thin controller vs. Service layer

and here is an approach where the viewmodels are populated using an adapter of sorts http://paulstovell.com/blog/clean-aspnet-mvc-controllers