I highly recommend reading
http://www.lostechies.com/blogs/jimmy_bogard/archive/2009/04/24/how-we-do-mvc.aspx
Here's my incomplete list of what controller shouldn't do:
- bind post data to view model - no, model binders should do this
- get entities from repositories - I'd say no, model binders or action filters should
- calculate something - no, view models or entities should
- authorization - maybe, but it's better pass to attributes/filters
- validation - only if it come back from entities/domain (i.e. business rules), view models (presentation) validation should be handled automatically (binders, etc)
Should do:
- get bound, validated view model as input
- call domain layer, passing data from view model
- handle domain layer errors
- route to appropriate action/view depending on view model / domain results
Bad:
public ActionResult PlaceOrder(Guid orderid)
{
if (HttpContext.Session["user"] == null)
return Redirect("Login");
if (!ValidOrderId(orderid)) return Redirect();
var order = cart.Get(orderid);
if (order == null) { ViewData["orderid"] = orderid; return View("Select"); }
order.Status = OrderStatus.Placed;
foreach (var item in order.Items)
item.Update();
var cart = Cart.GetCurrent();
cart.Save(order);
return Redirect("Show", "Orders", new { orderid = orderid });
}
Good
[Authorize]
[ModelStateToTempData]
// OrderViewModel.Id/OrderViewModel.Instance - validates id,
// gets it from repository, set Instance or ModelState error
public ActionResult PlaceOrder(OrderViewModel<Order> order)
{
if (!ModelState.IsValid)
return View("Select", order);
var order = order.InstanceFromDatabase;
_injectedCart.SetOrderPlaced(order);
return RedirectToAction<OrdersController>(c => c.Show(order));
}
And by the way, I rarely see good MVC examples, including the NerdDinner. They all deal with business logic inside actions, no view models, and so on. This is usually OK for what they are intendet for - MVC features demonstration - but it shouldn't be taken as good design examples. A more-or-less good examples is CodeCampServer, along with accompanion book ASP.NET MVC In Action. But not without its drawbacks (anemic domain model, for example).
But if do not try to follow domain driven design, and instead have a simple data-driven requirements, things can be easier for you.