Hi folks,
I am new to this forum. First of all i would like to congratulate the guyz who designed this forum esp. Ed who conceived this. And i find you guys to be very enthusiastic and extremely good at responding to the discussions.

Well here is a question i have been trying to get answers to:
I have come across multiple design patterns. Some where the architect has used a single servlet and others where there was a servlet for each function. Are there any measurable pros and cons in either approach. I believe some have to say that having one servlet in memory all the time is better than 10 more. But what if that one servlet is too huge and far more cumbersome than splitting the design into multiple servlets.
Any tips would really help.

why do you want many servlets in the first place, thats bad design. as you mentioned use one servlet as a dispatcher talking with bunch of class files.

It makes sense to use multiple servlet classes/instances for initialization and/or representing separate modules under a single application.

The question i have for the solution with one servlet is that how do you get the parameters from the HttpServletRequest. Say i have 3 types of data entry forms : Employee, Department, Systems. In each case the HTTP request will have unique parameter names EMP_ID in one, DEPT_ID in 2nd and SYS_ID in the third.

As these parameters are specific to the PResentation (HTML), if i have more than say 10 forms i have to decipher each parameter in my servlet. This would make it very long. I believe keeping multiple servlet say EmployeeServlet, DepartmentServlet and SystemServlet makes more sense.

I am not sure how to do this with one servlet without witing complex if/else statements with say a method for each Use Case.

Any feedback/comments would help.

This question is highly case-specific meaning it varies from application to application. But here are the few points that I think might help take that decision.

1. It really doesnt matter too much if the servlet is too long or not except for the maintenance issues and thread safety issues. Its always a good idea to break the servlet in to decent size (maintainable entities). Memory issues are more or less nonexistent in this age as you have servers with 2GB memory very commonly deployed for production systems.

2. We use pattern (to avoid too many if-else statements) to handle all the actions handled by the servlet (cant disclose it here its properitery stuff)

3. If you have to communicate too much between the multiple servlets than its a bad design. As it would indicate merging the 2 servlets to avoid overhead of inter-servlet communication.

There are other issues to .... but I guess this should help.

Ritesh
(billion26 at yahoo dot com)

I can fill you in on a pattern that works for eliminating the multiple if-then statements in the single-servlet solution. Just look at the Strategy pattern and Command pattern in the Gang of Four Design Patterns book.

Basically, you just have commands loaded as keys into a HashMap. Each command is mapped to an object that imlements some standard handler interface.

I have been using this solution for servlets for about three years with great success.

right on, this is in the lines of what i had mentioned before.

The benefit of using one servlet as a dispatch servlet is that it provides a gateway into your application, and you can have common business logic in one place (such as if a user is logged in or not). A common way to do this is to have your single dispatch servlet map some request parameters to different states. You would always have one parameter be the state parameter. For example:
DispatchServlet?state=employeeForm or
DispatchServlet?state=departmentForm

DispatchServlet would then have to map that state parameter to the appropriate action.