Bitter servlets - Bitter Java - page 59

Notice the clarity of the model. It is infinitely more readable. As we have
come to expect, we can answer questions about extending the model much
more easily in the second example. Where could we add an overdrawn condi-
tion to the first example? What about the second? How would we credit inter-
est in the first example? What about the second? With our first antipattern, we
will review the same problem with a similar solution.

3.2 Antipattern: The Magic Servlet

Now we come to the most common server-side Java antipattern. The root of
this antipattern is a poor understanding and application of the principles of
Model-View-Controller. With this design pattern, our fundamental goal is to
establish a firm separation between the data model and the view, called model-
view separation . Both the model and the view must be implemented without
assuming anything about implementation details of the other. The controller
helps establish the connection between the two so that neither the view nor
the model must know about the internal details of the other.
We have seen the model-view-controller architecture applied many times
with client / server architectures. When we split architecture between client and
server, a common assumption that is usually not far from the truth is that the
model-view separation follows without much additional effort. On the client
side, we have view logic. On the server side, we have the model. The control-
ler is usually split between the two, with most of the implementation on the
server and in supporting software. Most client-server user interfaces are highly
interactive, so the model and view interface is not dramatically different from a
localized implementation. In fact, it is easy to become lazy and assume that
model-view separation will naturally fall along the client-server boundary.
We can get into serious trouble when we apply the same loose understand-
ing to servlet programming. Let's think back to my ride up the trail in the
Texas hill country. We have an easily visible danger and a hidden one. Because
we are using servlets, the lines between the client and server are clearly articu-
lated, are they not? The client, which represents the view, is simply the HTML
user interface. The servlet represents the model, and the software layers of our
chosen architecture will handle the tasks usually managed by the controller. As
we bike up this trail, our eyes are clearly on the rocks of the trail: the separa-
tion between the HTML view and the servlet.
We are about to be bitten by the hidden rattler. Unlike many interactive cli-
ent-server user interfaces, HTML has more of a batch-oriented architecture.
From the HTML code on the client, we will send an upstream HTTP POST to