Recently, fellow MVP and ASPInsider, Jeffrey Palermo blogged a pretty interesting idea called ActionController. Within his post, he states:
My interest in this space is purely practical. I really don’t care how patterns are published. I don’t care about “being true” to the MVC pattern or any other pattern. I’m more interested in being effective with web applications on .Net. After have experience with MvcContrib, CodeCampServer, and a much larger ASP.NET MVC implementation (200+ screens), I have come to see how controllers end up searching for an identity. What is a ProductController anyway? That’s just about as specific as classes called ProductService, ProductManager, ProductUtility, etc.
Jeffrey’s approach is pretty cool if you ask me since it puts a spin on how ASP.NET MVC is implemented. Jeffrey is trying to tackle the design (implementation) of actions within controllers by providing a different perspective on the issue. His approach is actually very similar to what Jakarta Struts provides within its framework; where an Action is the center all of execution and the controller takes a back seat during the request.
Now, I want to be clear that in no way shape or form, do I have disrespect for what Jeffrey is trying to test. He’s a very talented individual who’s very knowledgeable on the subject and I have the outmost respect for him.
Having said that, I think the following tweet might have been taken out of context:
What I meant by going “too far” was with regards to escalation of an action to the level of a controller. Granted, this is a simple spike and could be easily refactored into something leaner. I totally agree with Jeffrey that the discussion here is about the design of controllers and actions. In particular on how one thinks of controllers within their web application. The approach of the ActionController works extremely well when you mix both application logic as well as ‘request’ logic within your controller. In other words, your controller knows how to map against the request (http://mydomain.com/home/index) and also performs other logic within the action (interacting with repositories, domain, etc.).
A Little Bit of History…
For me, the approach for the controller is a little different due to my background with J2EE applications. When I first introduced with MVC, it was around a home grown MVC framework written in Java. The framework was loosely based around some of the concepts that were presented in the Web-Tier Application Framework Design section of the J2EE Blueprints.
Our home grown framework consisted of one servlet that handled all requests from the caller. Once a request was received, it iterated through a list of DataMappers to either fetch or persist data to the database then it would render the selected view. Pretty straightforward interaction for all the pieces within the request pipeline.
Other Java MVC frameworks such as Struts and SpringMVC follow a similar approach of defining a DispatcherServlet to handle all requests. Granted Struts handles things more at the action level, while SpringMVC does it at controller level. Which means that
My Approach
Now that you know some of my background, allow me to show you my approach for controllers within my MVC application. The following PostController source is from my yet another blog engine (yabe) sample MVC application:
namespace Mvc.Controllers
{
using System.Web.Mvc;
using Common;
using Models.Post;
using Services;
public class PostController : Controller
{
private readonly IPostService postService;
private readonly ICategoryService categoryService;
public PostController(IPostService postService, ICategoryService categoryService)
{
this.postService = postService;
this.categoryService = categoryService;
}
public ActionResult Index()
{
var posts = postService.RetrieveAll();
var model = posts.ConvertAll(dto => dto.ToViewModel());
return View(model);
}
public ActionResult New()
{
var categories = categoryService.RetrieveAll();
var model = categories.ConvertAll(dto => dto.ToViewModel());
return View(model);
}
public ActionResult Create(PostViewModel post)
{
var dto = post.ToDTO();
postService.Create(dto);
return RedirectToAction("Index");
}
}
}
As you can see in this contrived example, each of my actions are pretty small since all they do is handle the request, in the form of a ViewModel, then pass the ViewModel to the corresponding service for processing. If the service returns data in the form of Data Transfer Object (DTO), the result is then converted into a ViewModel and passed back to the View.
For my needs, this simple approach works. Not only that, I’ve also managed to keep the size of my actions pretty small. I’ve used this approach on the product developed, and it worked quite well with multiple Views/ViewModels. Also, other ASP.NET MVC sample applications such as Nerd Dinner and Oxite take a similar approach. Looking outside the ASP.NET MVC world, in this instance Ruby on Rails, they seem to follow a similar approach for their guides on developing controllers.
What’s your approach?