站内搜索: 请输入搜索关键词
当前页面: 图书首页 > JavaServer Pages, Second Edition

JavaServer Pages, Second Edition

[ directory ] Previous Section Next Section

6.5 SQL and Beans

In Listing 6.5, it is immediately obvious that 99 percent of it is manipulating the model梩he database梬ith only a single tiny line of view information announcing the completion of the task. This is just plain wrong!

The view layer has too much model, and using the SQL tags as in the previous section is fine for quick-and-dirty database applications. However, problems would soon arise when dealing with a larger, more complex site. If ten pages use some hard-coded SQL and then the structure of the database changes, it can be very difficult to find and fix all the problems. Although it may seem as though a database, once designed, should never change, requirements in the real world commonly shift over the course of a project.

The solution, as always, is to move the model layer, where it belongs, into some Java beans. Fortunately, this is a simple exercise, as beans and databases already have a great deal in common. A database row has a number of named columns, just as a bean has a number of named properties. A table can have many rows, just as an array can have many beans. In Chapter 5, these correspondences were used in a set of hard-coded beans to mimic a database. All that is necessary to complete the picture is to modify those beans so they connect to a real database.

Tools that will automatically build a class or bean that reflects a table are available. A very simple tool, Table2Bean, from Canetoad Software, is included on the accompanying CD-ROM. As its name implies, Table2Bean takes a SQL table definition and builds a bean. This bean can then provide easy mechanisms for interfacing with the underlying table.

To see how this will work, consider CDBean, generated from the table in Listing 6.1.

  1. If the cdId property is set, the bean will construct a SQL command, such as SELECT * FROM CD WHERE cdId= the provided id, execute this statement, and use the result to populate the rest of the properties.

  2. After loading the data, any property can be changed by using the normal set methods. The bean will also provide a special property, called save. If this property is set after any other properties have been changed, the changes will be saved back to the database with an UPDATE command.

  3. Similarly, if the save property is set before the cdId property has been set, the bean will assume that this is new data and will enter it into the database with an INSERT command.

  4. Finally, another special property, called beans, will return an array of beans that match the current properties. If a page sets the artistId field to 1, the beans property will return an array of all the albums from artist number 1.

The next chapter discusses how Java News Today will use these new beans, but the principles can be examined by seeing how they could be used to simplify the CD application. Listing 6.6 shows the new version of the page that displays all an artist's albums.

Listing 6.6 Retrieving data through a bean
<%@ taglib prefix="c"
    uri="http://java.sun.com/jstl/core" %>

<jsp:useBean
  id="cdBean"
  class="com.awl.jspbook.ch06.CdBean"/>

<jsp:setProperty name="cdBean" property="artistId"/>

<h2>Albums by
<c:out escapeXml="false" value="${param.name}"/></h2>
<ul>
<c:forEach items="${cdBean.beans}" var="cd">
<li><a href="<c:url value="show_tracks.jsp">
<c:param name="cd_id" value="${cd.cdId}"/>
<c:param name="name" value="${cd.name}"/>
</c:url>"><c:out value="${cd.name}"/></a>
</c:forEach>
</ul>

The only difference is that the sql:query tag has been replaced by a jsp:useBean and by jsp:setProperty tags; now the iteration goes over cdBean.beans. Although this is no shorter than the database version, the conceptual difference is huge. Now this page does not know whether the data is coming from a database or a serialized bean or is connecting to a Web site in order to get its information. The details of the model have therefore been hidden from the view, which is as it should be.

The difference is even more pronounced in the bean version of the page that adds an artist, which is shown in Listing 6.7.

Listing 6.7 Storing data through a bean
<%@ taglib prefix="c"
    uri="http://java.sun.com/jstl/core" %>

<jsp:useBean
  id="artistBean"
  class="com.awl.jspbook.ch06.ArtistBean"/>

<jsp:setProperty name="artistBean" property="name"/>

<jsp:setProperty
  name="artistBean"
  property="save"
  value="true"/>

New artist has been added!<p>
<a href="show_artists_beans.jsp">Return to the
artist list</a>

Now that's more like it! All the details of the ID are hidden away in the bean, so all the view needs to do is load the data and then tell the model to save itself.

One small detail has been glossed over in these last two examples: how these beans get the information necessary to connect to the database. This was passed in explicitly when using the SQL tags, but the beans are able to hide this information by using a feature of Java. It is possible for a Java class to load a resource given its name, so a resource called "db" that holds the connection information has been created, and the beans know to load that information when it is first needed.

    [ directory ] Previous Section Next Section