Guidelines: Designing Servlets
Topics
Introduction
This guideline focuses on designing of servlets. Additional guidance on servlets,
such as how to identify and model them, is provided by Guidelines:
Servlets.
Session State
Session state data managed by a servlet should be documented in the design
of the servlet. See Guidelines: 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 Guidelines:
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 Guidelines: 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.
|