Introducing JavaBeans
In Chapter 2 we introduced scriptlets, and touched on the problem associated with their excessive use
in JSP pages: as your JSP pages and application become more complicated, embedded scriptlets often
become longer and more complex. This will make your JSPs difficult to understand, and therefore
difficult to maintain. Not only this, but the functionality implemented in a scriptlet is tied to its JSP,
making it awkward to reuse this logic elsewhere.
In this chapter we are going to learn how to get around these problems by reorganizing our code into
components. One way to do this is move the data and functionality present in the scriptlets into
JavaBeans ("beans") instead. So, in this chapter we will be discussing:
-
How and why you should organize your code
-
How to use components to organize your code
-
What objects and classes are, and how to use them as components
-
How to create and use JavaBeans
Let's start then by considering how best to organize our code.
Organizing Your Code
When you are designing any application based upon JSPs there are three important considerations:
-
What are the tasks that the application will perform (and are any tasks repeated)?
-
What type of maintenance will the application require?
-
Who is responsible for the different parts of the application?
Let's now tackle each of these questions in turn.
Code Reuse
In simple applications that consist of only a small number of JSP pages, like the examples we have seen
in the first few chapters, any particular task may well be performed only once in the application.
However, in larger applications, the same task may be performed many times by many different parts of
the application. Rather than rewrite the same code time after time wouldn't it be better if we could reuse
code?
Why Reuse Code?
Intuitively, we know that reusing code is a great idea. But let's think about why this is true. By reusing
code we can:
- Speed up application development.
Obviously, if we reuse code, we have less code to write, so we can develop our application more
quickly. Not only this, but if we reuse code, the final application will be smaller, and therefore will
probably have fewer bugs. Indeed, debugging the application should be easier anyway, because there
will be fewer lines of code to wade through.
- Ease maintenance of the application.
Consider a JSP web application that stores data in a database. Connecting to the database and retrieving
data are tasks that the application performs.
Using the techniques we have learnt so far, the Java code to perform these tasks would be contained in
scriptlets. The scriptlets would have to be repeated in every JSP page that required database access.
But what happens if we want to change the database system used by the application, for example from
Oracle to SQL Server? In this case, the application developer would have to change the database access
code in every scriptlet. In a small application this could mean changing the code in only a few pages.
However, in a large application the code in hundreds or thousands of pages would have to be changed.
There are two reasons why such a change is a problem. Firstly, the changes are tedious and time
consuming to make. And we all know that "time is money"; the developer's time could be better spent
improving the application. Secondly, the more code the developer changes, the more danger there is of
introducing new errors into the code.
Both of these problems can be avoided if instead of repeating the same code in many different parts of
an application, the code is written once and accessed by the different parts of the application when they
need it.
Separation of Roles
If we consider a typical e-commerce web site which uses JSPs, the maintenance of the site often falls to
two distinct groups of people: the designer and the developer. The role of the designer is to maintain the
presentation, or look and feel, of the site. The developer is responsible for the functionality or logic of
the application. The logic of the application is the Java code that provides things like database access
and the business rules.
There may be a clear separation of these roles or there may be some degree of overlap between them.
The key point is that when you are thinking about the design of the page, you do not want to have to
worry about the Java code that provides functionality. As a designer you want to treat tasks like
database access as "black boxes". That is, you put something in and get something out but you are not
interested in what actually happens inside. As a developer, you don't want to worry about how the data
that you look after is displayed or passed to web site clients.
This separation of roles leads to the organization of the application into layers or tiers. It was explained
in Chapter 1 that JSP is the presentation tier of the J2EE architecture. There are other parts of the
architecture that are responsible for data access and business logic, some of which we will come across
later in this chapter and in Chapter 12. In our JSP web applications we should adopt a similar approach.
New on the Java Boutique:
New Review:
Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling
API boasts simplicity, ease-of-integration, a well-rounded feature
set, and it's free!
New Applet:
Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA
sequences into three useful formats.
Elsewhere on internet.com:
WebDeveloper Java
Lots of Java information on webdeveloper.com
WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.
ScriptSearch Java
Hundreds of free Java code files to download.
jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.
| 
