MVC Philosophy


Web tier: servlets, JSP, Web frameworks: MVC Philosophy

  1. MVC Philosophy (1 messages)

    While I understand the value of MVC, I am beginning to wonder if MVC implementations that use a Servlet controller are of any great benefit.

    It seems that the function of a controller is to map requests to appropriate views. Generally, some sort of pre-processing functionality that interrogates the model accompanies the mapping. A framework like Struts implements this as a configurable controller Servlet with Actions that encapsulate the pre-processing functionality.

    However, isn't a Servlet engine like Tomcat or Resin already a controller; and don't Servlet Filters encapsulate pre-processing functionality? When I configure a Servlet engine, I map requests to resources. When I configure Struts, I map requests to resources. If I need pre-processing with plain Servlets, I associate a Filter with a URL. If I need pre-processing with Struts, I associate an Action with a URL.

    Sure, Struts and other controller Servlet frameworks offer many non-trivial niceties; but they seem superfluous to the core responsibility of a controller, and it seems these extras could be just as easily placed in Filters. So I'm having a difficult time seeing any major benefits that having a Servlet as a controller brings. Why not just consider the engine itself to be the controller and use Filters for pre-processing?

    Any insights would be appreciated.

    Threaded Messages (1)

  2. MVC Philosophy[ Go to top ]

    As I've read in many articles, struts provides a framework to get your development off on the right foot and running. You can always homegrow your own approach, something I've been involved with on several occasions with different shops. But then you need to invest your time in the initial development. Whereas this work is done for you with a framework like struts and due to its community support it is ever evolving.

    But I'm not sure the logistics of using filters would be a better solution:

    I thought filters only intercepted a request prior to being handled off to a servlet or a jsp? I don't believe they are intended to be act as a controller.

    Plus how would a filter controlling mechanism function better? Would you have a filter for each request? Seems like a lot of unesscessary duplication. Or if you use a single does this differ from a single servlet. Don't forget that the mvc in struts not only maps requests to a particular action but also to the resultant jsp page depending on the outcome of the action processing So somehow you would need to figure out the actual final destination of this request, so the multi-filter approach doesn't look to appealing.

    In addition the nicities are actually part of the whole package and shouldn't be considered bonus material. Your gaining the retrieval, population, and validation of form inputs with struts as well as I18N and error handling.