Question

I am probably over analyzing here, but with all the reading I have done on MVC, there seem to be so many opinions on how to do things.

Is there a “Best Practices” site or document out there that defines the responsibility of each piece of MVC?

The few questions I have, keep in mind I am using the EF/Repository&UnitOfWork/Service pattern are:

1) How to get the validation results (error messages, etc) of Domain Objects and Business Rules from the Service Layer to the View Models?

2) I am using Domain Objects and a Service Layer that does all the Business Logic, then I send the Domain Objects to the controllers and let them (via AutoMapper) convert them to View Models for the views. What other types of things are the responsibility of the controller? Is the following code OK? Is this too much logic in the controller?:

public ActionResult SomeAction()
{
    var model = Mapper.Map<DomainObject, ViewModel>(service.QueryReposForData());
    model.SomeCollectionForSelectList = Mapper.Map<IEnumerable<DomainObject>, IEnumerable<ViewModel>>(service.QueryReposForSelectListData());
    return View(model);
}

I don’t think that the only thing in a controller is one line that returns a view with an object graph mapped to view models?

3) I think it is OK to have properties on the ViewModels that can indicate to a view if something can be hidden for example and then perform that logic in the view? Example:

@if(Model.DisplaySomething)
{
    <div>Something to show</div>
}
else
{
    <div>Something else to show</div>
}

4) I was thinking of having my services return some sort of TransactionResult object back to the controllers on writes to make it the responsibility of the service to handle the transaction. So I would have an aggregate service that would start a transaction (UnitOfWork) do what ever it needed to do and then return this TransactionResult that could have error messages? I don’t think I should make the controller responsible for managing the transaction, but rather have it just pass in a view model mapped to a domain object to the service and let it act on it?

5) Also, how much of ActionFilter’s do you want to use? I know it is a huge extensibility point, but I often find myself trying to stuff all of the model creation into a filter.

Answer 1

Just opinions here based on how we work.

We keep our Controllers so skinny they are anorexic, in almost every case.

As for ViewModels, we follow the pattern of having a ViewModel for every view. The Controller loads it up with anything it needs, and kicks it off. From there, the ViewModel drives everything. In our world, the ViewModel is tied directly to the view and contains no code that would/could be used in other parts of the application. It interacts with any part of the larger ‘Model’ (service layer, etc) that it needs to and packages stuff up for the View to consume.

For your #3 example, I’d say absolutely yes – it’s the way we use our ViewModels.

Again, none of this is gospel – just my take on how we handle it.