The Problem with Servlets
In many Java servlet-based applications, processing the request and generating the response are both handled by a single servlet class. Example 3-1 shows how a servlet class often looks.
public class OrderServlet extends HttpServlet {
public void doGet((HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
response.setContentType("text/html");
PrintWriter out = response.getWriter( );
if (isOrderInfoValid(request)) {
saveOrderInfo(request);
out.println("<html>");
out.println(" <head>");
out.println(" <title>Order Confirmation</title>");
out.println(" </head>");
out.println(" <body>");
out.println(" <h1>Order Confirmation</h1>");
renderOrderInfo(request);
out.println(" </body>");
out.println("</html>");
}
...If you’re not a programmer, don’t
worry about all the details in this code. The point is that the
servlet contains request processing and business logic (implemented
by methods such as isOrderInfoValid() and
saveOrderInfo( )), and also generates the response
HTML code, embedded directly in the servlet code using
println( ) calls. A more structured servlet
application isolates different pieces of the processing in various
reusable utility classes and may also use a separate class library
for generating the actual HTML elements in the response.
Even so, the pure servlet-based approach
still has a few problems:
Thorough Java programming knowledge is needed to develop and maintain ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access