Introduction
This guideline focuses on designing of servlets. Additional guidance on servlets, such as how to identify and model
them, is provided by Guideline: Servlets.
Session State
Session state data managed by a servlet should be documented in the design of the servlet. See Guideline: Designing State for J2EE Applications for additional guidance on session
state.
Servlet Context
Any interactions with the servlet context should be documented in the design of the servlet. Servlet context is data
global to the application, and should be managed carefully. See Guideline: Designing State for J2EE Applications for additional discussion of this
mechanism.
Longer-Lived State
A servlet may also manage data intended to outlive a single client session. For example, it may directly access a
database via JDBC, or it may store data in cookies on the client side.
If a servlet manages such longer-lived data, this should be stated in the description of the servlet in the Design
Model. The design of longer-lived state is also discussed in Guideline: Designing State for J2EE Applications
Granularity
Servlets can invoke other servlets, JSPs, helper classes, and EJBs. If a servlet is becoming too large, consider the
following options:
-
introducing helper classes that can be separately unit tested.
-
moving all HTML code into JSPs
-
pushing any business logic into EJBs.
Generally servlets deal with non-persistent session state, and so do not require transactions. If transactions are to
be used, then guidance for when to use them should be specified in the project-specific design guidelines.
|