Mapping Data Objects Simply (Continued)

SQL Statement
This mapping process includes two parts: one is to create a dynamic insert SQL statement and the second is to run the created SQL statement on the database. Listing 2 show this process as a function. The first step in this process gets the list of fields from the data bean, and then traverses the list to construct the insert SQL statement. Using the same introspection techniques on the data bean, the code gets the list of declared fields. The Field object is then used to get the corresponding getter method, which is further invoked to get the value of the field. While constructing the statement, the field type is used to format the dynamic statement according to the SQL syntax.

Once again the key in this mapping is the assumption that the name of the fields in the data bean are the same as those in the corresponding table. Listing 2 shows the process for data insertions, but the same concept can be extended for update and delete commands.

Programmatically speaking, this process should be called to map the result set to the data bean object array, instead of the table to the data bean (see Listing 3). The initial part of the process is to get a result set populated from the passed SQL, and the latter part performs the real mapping.

The ResultSetMetaData object holds complete information about the types and properties of the columns in a ResultSet object. This information, along with the standard introspection technique, provides the basic building block for this mapping process. Before looping through the result set, the code traverses through the list of result set columns and creates corresponding Field and Method objects. These objects are then used for populating data in the newly created data bean for every record in the result set.

Column data field mapping is performed only for fields that are present in the result set column list. All other fields will have their default initialized values. This process follows the same technique: introspect the data bean, get Method objects, and use the objects to get data from the bean. The only difference here is that a list of field names is provided to force the sequence of columns in which the HTML table will be rendered. The code takes an array of data beans and an array of field names (see Listing 4). The code generates a basic HTML table, but it can be spiced up with a different style sheet or HTML tags specific to your project.

All the mapping processes discussed here use a simple data bean or a simple data structure. By "simple" I mean one-to-one mapping between HTML form, data bean, and database table. The technique can be extended to accommodate a more complex data structure and relations. It can be used in different ways and in different scenarios, but personally it's a good candidate to fit in a DAO pattern for Web applications.

In a separate, stand-alone utility, I have extended this technique to generate data-bean and HTML-form code from the database table. This utility makes sure that the name of the fields are the same across the project, and it saves me form the monotonous process of writing the data bean and the HTML form.

Efficiency can be a concern for heavy traffic applications, but efficiency is always a relative term. Any object-relational mapping process will have some performance hit compared to hand-coded SQL code and data mapping using getter and setter methods. The advantage these mapping processes bring can be argued against efficiency concerns. Once in place, this mapping process can really save a lot of development and maintenance time for most of the project. Don't underestimate a quick development time and easy maintenance, especially in today's information age where GHz speed and GB memory size are a way of life.

About the Author
Probir Goyal is a Sun-certified enterprise architect and senior application developer for a telecommunication company. Contact Probir at .