</td><td class="td" align="left">
<p class="table-para">Low</p>
</td><td class="td" align="left">
<p class="table-para">Medium</p>
</td><td class="td" align="left">
<p class="table-para">Medium</p>
</td>
</tr>
<tr valign="top">
<td class="td" align="left">
<p class="table-para">
<b class="bold">Maximize code portability</b>
</p>
</td><td class="td" align="left">
<p class="table-para">Medium</p>
</td><td class="td" align="left">
<p class="table-para">Medium</p>
</td><td class="td" align="left">
<p class="table-para">High</p>
</td><td class="td" align="left">
<p class="table-para">High</p>
</td><td class="td" align="left">
<p class="table-para">High</p>
</td>
</tr>
<tr valign="top">
<td class="td" align="left">
<p class="table-para">
<b class="bold">Minimize vendor reliance</b>
</p>
</td><td class="td" align="left">
<p class="table-para">High</p>
</td><td class="td" align="left">
<p class="table-para">Medium</p>
</td><td class="td" align="left">
<p class="table-para">Medium</p>
</td><td class="td" align="left">
<p class="table-para">Medium</p>
</td><td class="td" align="left">
<p class="table-para">Low</p>
</td>
</tr>
<tr valign="top">
<td class="td" align="left">
<p class="table-para">
<b class="bold">Maximize availability and fail-over</b>
</p>
</td><td class="td" align="left">
<p class="table-para">Low</p>
</td><td class="td" align="left">
<p class="table-para">High</p>
</td><td class="td" align="left">
<p class="table-para">High</p>
</td><td class="td" align="left">
<p class="table-para">Low</p>
</td><td class="td" align="left">
<p class="table-para">Low</p>
</td>
</tr>
<tr valign="top">
<td class="td" align="left">
<p class="table-para">
<b class="bold">Manageable via JTA</b>
</p>
</td><td class="td" align="left">
<p class="table-para">Yes</p>
</td><td class="td" align="left">
<p class="table-para">Yes</p>
</td><td class="td" align="left">
<p class="table-para">Yes</p>
</td><td class="td" align="left">
<p class="table-para">Yes</p>
</td><td class="td" align="left">
<p class="table-para">Yes</p>
</td>
</tr>
</tbody>
</table>
<a name="141"></a><a name="IDX-54"></a>
<p class="para">
<b class="bold">Minimize the learning curve.</b> Because JDBC was the first persistence API for databases, it is the most familiar to most, if not all, Java developers and thus has the lowest learning curve. The learning curve for entity beans with container-managed persistence is widely acknowledged to be large. To use entity beans with bean-managed persistence, developers need to understand both JDBC and entity beans. JDO and most O/R toolsets have learning curves that are higher than JDBC and lower than entity beans.</p>
<p class="para">
<b class="bold">Minimize code and configuration files written and maintained.</b> People have a tendency to consider the number of lines of code only when evaluating ease of development. I view any configuration file (e.g., an entity bean deployment descriptor) as code with a different syntax. Hence, I don't see entity beans as having less code or simpler code than JDBC. JDO and most O/R toolsets I'm familiar with save some percentage of code in most situations.</p>
<p class="para">
<b class="bold">Maximize the ability to tune.</b> Because it's the lowest level API and closest to the database, JDBC provides unfettered ability to tune database SQL. Every other choice relies on a product to generate the SQL used. For instance, most object-relational mapping tools generate the SQL executed; it's usually harder to tune without direct control of the SQL used.</p>
<p class="para">
<b class="bold">Minimize the deployment effort.</b> Deployment hassles negatively impact development and maintenance time. Changes in JDBC code require just a recompile, whereas entity bean changes require a recompile, stub generation, <a name="142"></a><a name="IDX-55"></a>and redeployment of the bean. JDO implementations and O/R toolsets may require more work than a recompile but usually less than a bean change.</p>
<p class="para">
<b class="bold">Maximize code portability.</b> Being able to easily port code to different databases is important. Although you can write portable JDBC code, a significant percentage of JDBC code uses some database feature that's proprietary and not portable. Entity beans with BMP contain JDBC code and get the same grade. Entity beans with CMP don't have JDBC code, but they do have mappings and sometimes SQL statements in the deployment descriptors. If the SQL statements use a proprietary database feature, there's a portability issue, but the magnitude of the problem would likely be smaller. The same could be said of most JDO and O/R toolset implementations.</p>
<p class="para">
<b class="bold">Minimize vendor reliance.</b> You need to reduce your dependence on vendors that provide J2EE container services, JDBC drivers, JDO drivers, and O/R toolsets. This is desirable from a business standpoint should a vendor fail or change its cost structure. You can change vendors for JDBC drivers easily; I've done it many times with multiple database vendors.</p>
<p class="para">Changing container vendors is moderately easy. You do have the possibility of performance-tuning issues, particularly with CMP and JDO vendors. With O/R toolsets, application code directly uses vendor (or vendor-generated) classes. Switching O/R toolsets requires significant development in most cases.</p>
<p class="para">
<b class="bold">Maximize availability and fail-over.</b> Most of the time, availability and fail-over are provided by the container or database vendor. With the possible exception of entity beans, the persistence method adds absolutely nothing to fail-over. Entity beans, both CMP and BMP, are excepted because the container has more control and can provide better fail-over services. However, fail-over capabilities in this regard are largely dependent on your container vendor.</p>
<p class="para">
<b class="bold">Manageable via JTA.</b> The Java Transaction API (JTA) is the part of the J2EE specification that provides the two-phase commit functionality. Many developers appear to be under the impression that to use two-phase commit functionality, you need to use entity beans. That's not true. As long as you're able to manage transaction commits and rollbacks via JTA, you can get the two-phased commit functionality.</p>
<p class="para">Although I've seen selected use of entity beans, JDO, and O/R toolsets, most of my clients manage persistence using native JDBC. JDO use seems to <a name="143"></a><a name="IDX-56"></a>be getting more press and may indeed be the fastest-growing JDBC alternative, but it hasn't pervaded the market yet.</p>
<p class="para">I think about the use of software toolsets in the same way an economist thinks about market efficiency. Financial analysts and economists have a theory that financial markets are efficient. That is, when a new piece of information becomes public, the stock prices of all companies related to that information change accordingly over time. For example, when the Enron and United Airlines bankruptcies became publicly known, the news had profound effects on their stock prices.</p>
<p class="last-para">When new software paradigms are introduced, if they provide benefits that exceed their costs, over time developers will switch to them. The time frame in which this happens for programming paradigms is much slower than that for financial markets, but the general concept is much the same. The "market" consensus regarding database persistence appears to be favoring native JDBC at the moment. If developers do in fact migrate to the more productive software paradigms over time, the inference would be that native JDBC persistence is the best choice for most applications.</p>
</div>
<div class="section">
<h3 class="sect3-title">
<a name="144"></a><a name="ch05lev2sec2"></a>Simplified Data Access Pattern</h3>
<p class="first-para">Of the two patterns for data access objects that are most common, this is the simplest. In this pattern, there is a one-to-one correspondence between the physical storage construct (e.g., relational database table, XML document, or file) and the DAO that manages it. For example, you might have <span class="fixed">CUSTOMER_DAO</span> manage access to a <span class="fixed">CUSTOMER</span> table in a relational database. Although you haven't identified methods yet, you can imagine that this class will have methods to search and return information on one or more customers using search criteria as arguments. It might have methods to insert, update, and delete customers as well.</p>
<p class="para">The advantage of this pattern is that it's simple. Its chief disadvantage is that it's often specific to one data source type. The code involved in manipulating an XML document is quite different from the JDBC and SQL required to use a database table. Switching the data source type would be a major overhaul to most methods in the class.</p>
<p class="para">This pattern is usable no matter what database persistence mechanism you choose. If data access will be managed by an entity bean, that entity bean would in essence be your DAO. The same could be said for a class using native JDBC, JDO, or an O/R toolset. <a class="internaljump" href="#ch05fig02">Figure 5.2</a> illustrates an object model for this pattern.</p>
<div class="figure">
<a name="145"></a><a name="ch05fig02"></a><span class="figuremediaobject"><a href="images/fig73%5F01%5F0%2Ejpg" NAME="IMG_3" target="_parent"><img src="images/fig73_01.jpg" height="263" width="329" alt="Click To expand" border="0"></a></span>
<br style="line-height: 1">
<span class="figure-title"><span class="figure-titlelabel">Figure 5.2: </span>A Simplified Data Access Pattern</span>
</div>
<a name="146"></a><a name="IDX-57"></a>
</div>
<div class="section">
<h3 class="sect3-title">
<a name="147"></a><a name="ch05lev2sec3"></a>Supporting Multiple Databases</h3>
<p class="first-para">For an application that supports multiple types of databases, the data access object pattern, which is factory based, is quite common. This pattern implements the DAO as an interface. A factory is required to produce objects that implement this interface. In addition, you will have an implementation of this interface for each type of data source. The factory is smart enough to know how to instantiate all implementations. <a class="internaljump" href="#ch05fig03">Figure 5.3</a> illustrates an object model for this pattern.</p>
<div class="figure">
<a name="148"></a><a name="ch05fig03"></a><span class="figuremediaobject"><a href="images/fig74%5F01%5F0%2Ejpg" NAME="IMG_4" target="_parent"><img src="images/fig74_01.jpg" height="198" width="350" alt="Click To expand" border="0"></a></span>
<br style="line-height: 1">
<span class="figure-title"><span class="figure-titlelabel">Figure 5.3: </span>Data Access Object Pattern</span>
</div>
<p class="para">For example, consider a customer DAO implementation. It would have a <span class="fixed">CustomerDAO</span> interface that would specify a variety of search methods as well as an update, delete, and insert method. It would also have a customer DAO factory (<span class="fixed">CustomerDAOFactory</span>) responsible for providing a DAO for the application to use. It might also have an implementation for all relational databases it supports (e.g., <span class="fixed">CustomerDAOOracleImpl</span>, <span class="fixed">Customer-DAOSybaseImpl</span>, <span class="fixed">CustomerDAOMySQLImpl</span>, etc.). The business object code would use the <span class="fixed">CustomerDAO</span> interface exclusively so it could use any one of the implementations.</p>
<a name="149"></a><a name="IDX-58"></a><a name="150"></a><a name="IDX-59"></a>
<p class="last-para">
<b class="bold">The data access object pattern is overkill if you don't foresee a need to support multiple database vendors.</b> Few business applications need to be able to do this. Software vendors are more likely to need this pattern than business application users. I discuss it at length because it has an unqualified recommendation in many texts.</p>
</div>
</div>
</div><br>
<table width="100%" border="0" cellspacing="0" cellpadding="0">
<tr><td><div STYLE="MARGIN-LEFT: 0.15in;"><a href="toc.html"><img src="images/teamlib.gif" width="62" height="15" border="0" align="absmiddle"  alt="Team LiB"></a></div></td>
<td align="right"><div STYLE="MARGIN-LEFT: 0.15in;">
<a href="LiB0030.html"><img src="images/previous.gif" width="62" height="15" border="0" align="absmiddle" alt="Previous Section"></a>
<a href="LiB0032.html"><img src="images/next.gif" width="41" height="15" border="0" align="absmiddle" alt="Next Section"></a>
</div></td></tr></table>
</body></html>