Action-based or Component-based MVC?

Which type of MVC framework to use: action-based or component-based? A very opinionated topic to say the least and has many pros and cons to both sides of the argument. I’m going to provide some insight from my experience into this area of discussion and hopefully keep the discussion to facts and not market hype (“fluff” as I call it).

The Case for Action-Based MVC Frameworks
Action-based MVC frameworks were introduced about the time of Struts (some would argue that it was Struts that brought about the term). The basic premise of the action-based design is that for each user request into the application, these are considrered “actions”. Each action would have a mapping and a flow from the request to the object responsible for request handling to the view representing this action result, looking like this:

This design gives us a very fine-grained flow and makes the application web-tier very simplistic in terms of keeping up with which request is handled by which object(s) and is presented with which view. The benefits of this are many, including: ease of development; quick ramp-up time for new developers; easily tested using a browser. The drawbacks of this design include, among other minor issues, that the application project will become very large in the MVC management with any site consisting of more than a few pages. Another drawback is the lack of “collecting” the common actions into single objects (each action has its own object) – so if you had 30 actions, you would likewise have 30 configurations of action mappings along with 30 objects.

The Case for Component-Based MVC Frameworks
Component-based MVC frameworks provide a coarse-grained design and were born out of the desire for many architects to “collect” actions related to the same type of data together into groups. This means that if you have actions for ‘login’, ‘logout’ and ‘getAccount’ that these could be grouped together into one component called ‘AccountController’, for example. This controller object would then handle all account-related actions. The benefits of this design are: easy testing; small project footprint at the action level (actions essentially are methods); simplified configuration. The drawbacks of this design include: having to read code to determine presentation view (could be handled in configuration); multiple developers potentially working on same component at same time. The following is an overview of component-based design flow:

My Recommendation
Whether using an MVC framework or handling MVC on your own, I suggest that you first decide how big the project is going to potentially be. Of course no one has a crystal ball, however if the application is a storefront with displays of products and handling credit card information for payment, then it’s small enough that action-based will be sufficient. On the other hand, if the application is an online portal then most likely you should use the component-based design. It has been my personal experience that most applications are better off using the component-based design. I have worked with many clients and their employees in which the decision of which type of MVC framework to use was based purely on whichever one they had experience with – this is absolutely the worse way to design an application. Application design should be done by someone with no reservations as to which tools to use – rather to design the application with the best tool for the job. Deciding on the best tool for the application has nothing to do with how much experience one has with said tool.

http://shaunchilders.com/node/8

Difference between Request MVC and Component MVC

In request (action) based MVC, a single front controller servlet will delegate to action models based on request URL/params. You works directly with raw HttpServletRequest and HttpServletResponse objects in the action model. You’ve to write code yourself to gather, convert and validate the request parameters and if necessary update the model values before you can ever invoke the business action.

In component based MVC, a single front controller will gather, convert and validate request parameters and update the model values itself so that you only need to worry about the business action yourself. How the controller needs to gather/convert/validate/update the values is definied in a single place, the view. Since that’s not possible with “plain” HTML, a specific markup language is required to achieve the goal. In case of JSF 2.0, that’s XML (XHTML) based. You use XML to define UI components which in turn contain information about how the controller should gather/convert/validate/update the values and itself generate the necessary HTML representation.

Advantages and disadvantages should be clear at this point: With a request based MVC framework you need to write more code yourself to achieve the goal. However you end up with much more fine grained control over the process and the HTML/CSS/JS output. With a component based MVC framework you don’t need to write much code yourself. However you have less fine grained control over the process and the HTML/CSS/JS output. So if you’d like to do things a bit differently than the standard describes, you’ll waste a lot more time in a component based MVC framework.

See also:

• Design patterns in Java webapplications
• What are the main disadvantages of JSF 2.0?

http://stackoverflow.com/questions/4801891/difference-between-request-mvc-and-component-mvc