📄 lib0086.html
字号:
<html>
<META http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<head>
<title>Architect's Exercise: ProjectTrak</title>
<link rel="STYLESHEET" type="text/css" href="images/xpolecat.css">
<link rel="STYLESHEET" type="text/css" href="images/ie.content.css">
</head>
<body>
<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="LiB0085.html"><img src="images/previous.gif" width="62" height="15" border="0" align="absmiddle" alt="Previous Section"></a>
<a href="LiB0087.html"><img src="images/next.gif" width="41" height="15" border="0" align="absmiddle" alt="Next Section"></a>
</div></td></tr></table>
<br>
<div class="chapter">
<a name="ch12"></a>
<div class="section">
<h2 class="first-section-title"><a name="412"></a><a name="ch12lev1sec5"></a>Architect's Exercise: ProjectTrak</h2><p class="first-para">ProjectTrak uses exclusively custom-coded data access objects as described in this chapter and does not use entity beans. Many work-scheduling software packages are deployed as stand-alone applications on client workstations. Although these requirements are not documented in the use cases for ProjectTrak, we don't want the application design to make a stand-alone client deployment difficult later. Using entity beans requires the services of a J2EE container. All data access objects in ProjectTrak use CementJ <span class="fixed">DbDataAccessObject</span> class and utilities.</p>
<p class="para">The data model for ProjectTrak is given in <a class="internaljump" href="#ch12fig02">figure 12.2</a>. There are twelve entities. As no denormalization will be applied to this data model, all entities are implemented as tables. I always use the database to enforce referential integrity rules. The referential integrity rules highlight some types of errors at the data access level and force developers to fix them early. Data access is supported by the data access objects shown in <a class="internaljump" href="#ch12fig3a">figures 12.3a</a> and <a class="internaljump" href="#ch12fig3b">12.3b</a>.</p>
<div class="figure">
<a name="413"></a><a name="ch12fig02"></a><span class="figuremediaobject"><a href="images/fig186%5F01%5F0%2Ejpg" NAME="IMG_33" target="_parent"><img src="images/fig186_01.jpg" height="254" width="350" alt="Click To expand" border="0"></a></span>
<br style="line-height: 1">
<span class="figure-title"><span class="figure-titlelabel">Figure 12.2: </span>Data Model Diagram for ProjectTrak</span>
</div>
<div class="figure">
<a name="414"></a><a name="ch12fig3a"></a><span class="figuremediaobject"><a href="images/fig187%5F01%5F0%2Ejpg" NAME="IMG_34" target="_parent"><img src="images/fig187_01.jpg" height="346" width="350" alt="Click To expand" border="0"></a></span>
<br style="line-height: 1">
<span class="figure-title"><span class="figure-titlelabel">Figure 12.3a: </span>Data Access Objects for ProjectTrak</span>
</div>
<div class="figure">
<a name="415"></a><a name="ch12fig3b"></a><span class="figuremediaobject"><a href="images/fig188%5F01%5F0%2Ejpg" NAME="IMG_35" target="_parent"><img src="images/fig188_01.jpg" height="374" width="276" alt="Click To expand" border="0"></a></span>
<br style="line-height: 1">
<span class="figure-title"><span class="figure-titlelabel">Figure 12.3b: </span>Data Access Objects for ProjectTrak</span>
</div>
<a name="416"></a><a name="IDX-170"></a><a name="417"></a><a name="IDX-171"></a><a name="418"></a><a name="IDX-172"></a>
<p class="para">Each entity is supported by a like-named data access object. For example, <span class="fixed">ProjectTaskDAO</span> provides reading/writing capabilities for the <span class="fixed">PROJECT_TASK</span> table. We might be tempted here to combine the reading/ writing logic for multiple tables into a single data access object. Although this would reduce the number of data access objects, it doesn't really reduce the workload because the JDBC work is the most time consuming. Combining the data access objects just relocates where the work resides, it doesn't eliminate any work.</p>
<p class="last-para">There is also value in consistency. Developers who weren't involved in the initial development will be able to find data access logic they need to work quickly and easily. If we combine access logic for multiple tables into a single data access object, it would take longer to find the logic we need to change.</p>
</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="LiB0085.html"><img src="images/previous.gif" width="62" height="15" border="0" align="absmiddle" alt="Previous Section"></a>
<a href="LiB0087.html"><img src="images/next.gif" width="41" height="15" border="0" align="absmiddle" alt="Next Section"></a>
</div></td></tr></table>
</body></html>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -