This week's book giveaway is in the Other Open Source APIs forum. We're giving away four copies of Storm Applied and have Sean Allen, Peter Pathirana & Matthew Jankowski on-line! See this thread for details.
All, I have a question that folks here at JavaRanch may be familiar with.
Using Tomcat's Specifications and the MVC pattern, is it better to use a single servlet controller or several servlets, one for each action, for a large application, in terms of container overhead and/or maintenance? e.g. SingleControllerServlet?UpdateDB SingleControllerServlet?RetrieveFromDB OR UpdateDBServlet RetrieveFromDBServlet In case 1, I send the function as part of the queryString while in case 2, each servlet performs its own function and has less logic processing to do. Thank you, cyberCipher
Sun Certified Java Programmer 2 (1.4)<br />Sun Certified Web Component Developer
First I had posted this in your other thread, but in case you haven't read it there yet. "cyberCipher"- Welcome to the JavaRanch! Please adjust your displayed name to meet the JavaRanch Naming Policy. You can change it here. Thanks! and welcome to the JavaRanch! Mark
Alright here are my two cents worth. I believe that a Servlet should be just that. The interface between the client and the server through a browser. It's responsibilities should remain to handle requests and responses on the web. Setting Headers, Content, etc. Anything that is business logic related should be delegated to "Helper" classes, rather than in the Servlet itself. Now, I also think your question is better handled by looking at the Web server, App server, and the pool of servlets to handle client requests. By configuring this correctly you will enhance performance. By making multiple Servlets I think the complexity and ability to maintain increases. Now, I am not an expert, and could be completely off in my beliefs, so taking my ideas with a grain of salt, and if someone else that is an expert cna better answer, than please do. Mark
Joined: Aug 26, 2002
Thank you, Mark, for your suggestions and responses. I agree with you that a servlet should be no more than a controller or an interface. Logic decisions must either be driven by the helper classes, javabeans, or helper files, maybe xml files. However, this may cause a significant memory overhead, instantiating the helper classes each time or I/O to search for the xml files. By using several servlets the complexity does increase and so does the maintenance since a problem has to be fixed in multiple places. However, who eventually wins the trade off between memory overhead and maintenance overhead. I believe that the maintenance overhead is more of an issue. Thank you, Maneesh
I think maintenance costs are much higher and more expensive all around than a memory issue. After all Ram and hardware are much cheaper. Mark p.s. Thanks for changing your name. However, you need to include your last name as well. Thanks [ September 04, 2003: Message edited by: Mark Spritzler ]
It's actually not that difficult to use just one controller. Here's the solution that I've come up with, it may not be the best, but it works pretty well: 1 controller servlet recipe -use something like /app/abcde instead of /servlet/controller?flow=abcde - you can pick apart the URL once you get to the controller. I do this instead of getting it from the request, plus it looks cleaner. -as far as getting input from the request, I have a filter set up that takes all the string data from the request and puts it in a map of name vs parameter, and passes it along to the servlet which passes it to the flow. That way you are not tied down to the HttpServletRequest. -set up a map wrapper that resolves flows to classnames, one that is loaded at startup and can be configured externally. Construct and cache the flows and dish them out on demand. The benefits are 1) external configuration for flows (may or may not be important) 2) simplification through reflection (cleans up controller code) 3) single entry/exit point for the View 4) You're pretty much forced to write decoupled code - which should help overall design and development. The disadvantages: 1) larger up-front cost, but done correctly, it's only a one-time cost and will reap larger benefits in the long run 2) if you like accessing the request/response/servlet objects directly and like to sprinkle business rules in with control and input logic, then this approach is not for you
Thank you for your response, Phil. I thought of another 1 controller design using xml mappings and reflection API that is similar to the one you mentioned here. I agree that the up-front costs are larger but the maintenance benefits alone are enough to 'run with it.' I do not have a problem with building this single controller framework but I was unsure about putting the work into it if the results were not what I expected. However, it seems that the 1 controller approach is a favorable one for several reasons. Thank you, Maneesh
Originally posted by maneesh subherwal: Thank you for your response, Phil. I thought of another 1 controller design using xml mappings and reflection API that is similar to the one you mentioned here. I agree that the up-front costs are larger but the maintenance benefits alone are enough to 'run with it.' I do not have a problem with building this single controller framework but I was unsure about putting the work into it if the results were not what I expected. However, it seems that the 1 controller approach is a favorable one for several reasons. Thank you, Maneesh
Take a look at Struts. It uses and xml config file to map urls to actions (the helper classes).