Benjamin,
My take is that the number of servlets should be minimized for performance reasons and that code that may be reused should be in utility classes. Generally, servlets are good for servicing requests (usually HTTP) and for control logic related to a web application. If the function of some code is not one of the these two, then consider moving it out of the servlet. Examples are business logic and database access.
Presentation should usually be in JSPs (for HTML) or could be in the servlet if JSPs are not used.
This approach enables common logic to be independent of the request protocol (HTTP). e.g. business code in a utility class could be reused directly by a
Java application or via RMI.
Note that this means HTTP concepts such as the request, session and response should not usually be passed to utility classes. The exception is when the utility class is really a helper class for the servlet (control, request parsing, HTML generation...).
Your example of passing the HttpRequest to the utility object is widely used in frameworks such as
Struts that employ a "Front Controller" servlet that handles all requests and routes them to various utility objects (Struts Actions). This means that only one instance of the servlet is required for the whole application and each request is handled by a lightweight
thread - a very efficient approach.
GMann (
SCJP,
SCJD, SCWCD, SCBCD)
"I'd rather have a bottle in front of me than a frontal lobotomy."