JavaServer Pages, Second Edition

3.1 Splitting Big Tasks into Manageable Pieces

As with any kind of engineering, software engineering is inherently difficult. No one person can build a bridge, plane, or building. The same is true of software beyond fairly small projects. Often a project is so big and complex that it simply cannot all fit into a single human brain.

For a large project to be manageable, it must be split into smaller pieces. This is true when many members of a team are working on the same project, so that each knows what part of the whole he or she will create. It is even true when a project is being undertaken by a single person. Splitting big problems into smaller ones allows the developer to concentrate on one thing at a time. Usually, the smaller pieces are easier to design, build, and test; once built, the individual components can be updated or changed without worrying about how that change will affect the rest of the system.

A difficult task can be partitioned in many ways. Java itself provides a natural unit of work in the form of classes, which will be discussed further in Chapter 9. Although these classes can help define the way work is done, the more fundamental question remains: what each class should do and which classes each developer should build.

One approach to this question advocates dividing the work into major functional units. This makes perfect sense, as it is the way most physical engineering is done. When building a car, one team is likely to be responsible for the engine, another for the electronics that controls everything, and a third for the exterior. These are natural ways to divide the work, as each piece is somewhat independent of the others and requires very different skills.

There is no set recipe for the way in which a software project should be divided, but over time, an important pattern that advocates dividing the project into three major pieces has emerged. The first piece will be responsible for modeling the problem to be solved and so is called the model. This model might be a virtual shopping cart for an online catalog, a database representing a CD collection, or a set of equations representing a complex scientific simulation. In each case, the model contains all the information about how the data is internally stored and the operations that may be performed on that data.

The second piece is responsible for allowing users to interact with this data. This could be a desktop application written in Java using the Swing API, or it could be an applet or even a program that controls a huge electronic billboard. The code for this piece contains everything needed in order to navigate through the data, display the values, modify the display as needed, and, possibly, allow the user to make changes to the model. Ideally, the presentation should also be aesthetically pleasing and intuitive to use. This piece is known as the view.

Finally, the third piece acts to mediate between the first two. Although it allows the user to request particular data, the view will not itself load that data into the model. In addition, some data may be restricted to certain users. Such security information should not reside in either the model or the view. So, the third piece, called the controller, is responsible for controlling the model, based on instructions from the view, and may also tell the view to hide certain information, based on data in the model.

In addition to identifying these three pieces, it is important to ensure that they all fit together and can interoperate. This is done by providing well-defined interfaces between each pair of components. The view will know how to get data from the model, the controller will know how to configure the view and the model, and so on.

Splitting the work in this way is known as the model/view/controller paradigm, and it is very powerful. Not surprisingly, JSPs will act as the view. The controller piece is not important for simple pages, and so discussion of it is deferred until Chapter 12.

That leaves the model. In the Java world, the model is usually composed of reusable software components called JavaBeans. These beans provide the logic behind the stock-purchasing system discussed earlier.

The importance of beans cannot be overstated. Besides being a fundamental Java specification in their own right, beans are the means for making JavaServer Pages do interesting and exciting things. Using beans properly allows sites to be built and maintained much more easily than they would otherwise. On the other hand, confusion about what belongs on a page versus what belongs in a bean can be a recipe for disaster. With that in mind, it's time to find out what these bean things actually are.