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:
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.
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.
No comments:
Post a Comment