?? lib0030.html
字號(hào):
<html>
<META http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<head>
<title>Chapter 5: A Layered Approach to J2EE Design</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="LiB0029.html"><img src="images/previous.gif" width="62" height="15" border="0" align="absmiddle" alt="Previous Section"></a>
<a href="LiB0031.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="ch05"></a>
<h1 class="chapter-title"><span class="chapter-titlelabel">Chapter 5: </span>A Layered Approach to J2EE Design</h1><a name="130"></a><a name="IDX-49"></a>
<div class="highlights">
<p class="first-para">Object modeling is a key skill for any technical architect with any object-oriented technology, such as J2EE. Object models are the most popular mechanism for documenting J2EE application designs. The technical architect is typically responsible for facilitating creation of an object model. This chapter presents and explains a general approach to designing J2EE applications. This discussion is necessary background to the <a href="LiB0038.html#184" target="_parent" class="chapterjump">next chapter</a>, which offers tips and techniques for transforming the use-case analysis described in previous chapters into a concrete design.</p>
<p class="last-para">J2EE application design is a vast topic. Entire books have been written about design techniques, design patterns, and object modeling with UML. And like most large and complicated methodologies, UML is only partially applied in business applications. Thus, although I don't want to discourage learning, I do take a streamline approach to the topic in this chapter. For instance, of the hundreds of design patterns that have been identified and cataloged, this chapter focuses on the handful of patterns most commonly used in business applications today.</p>
</div>
<div class="section">
<h2 class="sect2-title">
<a name="131"></a><a name="ch05lev1sec1"></a>Overview of the Layering Concept</h2>
<p class="first-para">A common framework for J2EE applications is <i class="emphasis">software layering</i>, in which each layer provides functionality for one section of the system. The layers are organized to provide support and base functionality for other layers. For <a name="132"></a><a name="IDX-50"></a>example, the data access layer provides a set of services to read and write application data. An inventory management application needs services that can read information about specific items and warehouses.</p>
<p class="para">Layering is not a new concept; operating systems and network protocols have been using it for years. For instance, anyone who's worked with networks is familiar with telnet, FTP, and Internet browsers. All these services depend on a TCP/IP networking layer. As long as the interface to TCP/IP services stays constant, you can make network software advances within the TCP framework without affecting telnet, FTP, or your Web-browsing capability. Typically, the TCP/IP layer requires the services of a device layer, which understands how to communicate with an Ethernet card.</p>
<p class="para">Applications can make strategic use of the same concept. For example, it's common to make data access a separate portion of an application so that data sources (e.g., Sybase or Oracle) can be changed relatively easily without affecting the other layers. The way the application physically reads and writes data may change without affecting application processing or business logic.</p>
<p class="para">To continue the inventory management example, suppose the data access layer had a method to look up the information for an inventory item given a UPC code. Suppose that other parts of the application use this method when information about items is needed (e.g., a customer viewing that item on a Web page or an inventory analyst ordering stock for that item). As long as the methods for access item information remain the same, you should be able to reorganize how you can store information about items and ware-houses without affecting the rest of the application.</p>
<p class="para">In essence, a layered approach mitigates the risk of technical evolution. If you use this concept to separate your deployment mechanics (e.g., servlets, enterprise beans), you can add new deployments without changing your business logic or data access layer. For example, Web services have become popular only within the last two years. If your application effectively separates your business logic and data access logic from the rest of your application, you can freely add a Web services deployment without having to change the entire application.</p>
<p class="para">
<a class="internaljump" href="#ch05table01">Table 5.1</a> lists common software layers used in J2EE applications. You can think of these layers as "roles." For instance, a customer object may have a role in the data access layer, the business logic layer, and the deployment layer.</p>
<a name="133"></a><a name="ch05table01"></a>
<table class="table" border="1">
<caption class="table-title">
<span class="table-title"><span class="table-titlelabel">Table 5.1: </span>Roles of Software Layers in J2EE Applications</span>
</caption>
<thead>
<tr valign="top">
<th class="th" scope="col" align="left">
<p class="table-para">
<b class="bold">Layer</b>
</p>
</th><th class="th" scope="col" align="left">
<p class="table-para">
<b class="bold">Role</b>
</p>
</th>
</tr>
</thead>
<tbody>
<tr valign="top">
<td class="td" align="left">
<p class="table-para">Data access object layer</p>
</td><td class="td" align="left">
<p class="table-para">Manages reading, writing, updating, and deleted stored data. Commonly contains JDBC code, but could also be used for XML document and file storage manipulation.</p>
</td>
</tr>
<tr valign="top">
<td class="td" align="left">
<p class="table-para">Business logic layer</p>
</td><td class="td" align="left">
<p class="table-para">Manages business processing rules and logic.</p>
</td>
</tr>
<tr valign="top">
<td class="td" align="left">
<p class="table-para">Value objects layer</p>
</td><td class="td" align="left">
<p class="table-para">Lightweight structures for related business information. These are sometimes referred to as <i class="emphasis">data transfer objects</i>.</p>
</td>
</tr>
<tr valign="top">
<td class="td" align="left">
<p class="table-para">Deployment layer</p>
</td><td class="td" align="left">
<p class="table-para">Publishes business object capabilities.</p>
</td>
</tr>
<tr valign="top">
<td class="td" align="left">
<p class="table-para">Presentation layer</p>
</td><td class="td" align="left">
<p class="table-para">Controls display to the end user.</p>
</td>
</tr>
<tr valign="top">
<td class="td" align="left">
<p class="table-para">Architectural component layer</p>
</td><td class="td" align="left">
<p class="table-para">Generic application utilities. Often, these objects are good candidates for enterprise-wide use.</p>
</td>
</tr>
</tbody>
</table>
<a name="134"></a><a name="IDX-51"></a>
<p class="para">
<a class="internaljump" href="#ch05fig01">Figure 5.1</a> illustrates how the individual software layers interrelate.</p>
<div class="figure">
<a name="135"></a><a name="ch05fig01"></a><span class="figuremediaobject"><a href="images/fig68%5F01%5F0%2Ejpg" NAME="IMG_2" target="_parent"><img src="images/fig68_01.jpg" height="251" 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.1: </span>Software Layers for J2EE Applications</span>
</div>
<p class="para">When this boils down to code, I usually implement the layers as separate packages. Here's an example package structure:</p>
<div class="informaltable">
<table border="0">
<tbody>
<tr valign="top">
<td class="td" align="left">
<p class="table-para">
<span class="fixed">com.jmu.app.dao</span>
</p>
</td><td class="td" align="left">
<p class="table-para">Data access object layer</p>
</td>
</tr>
<tr valign="top">
<td class="td" align="left">
<p class="table-para">
<span class="fixed">com.jmu.app.bus</span>
</p>
</td><td class="td" align="left">
<p class="table-para">Business logic layer</p>
</td>
</tr>
<tr valign="top">
<td class="td" align="left">
<p class="table-para">
<span class="fixed">com.jmu.app.vo</span>
</p>
</td><td class="td" align="left">
<p class="table-para">Value objects layer</p>
</td>
</tr>
<tr valign="top">
<td class="td" align="left">
<p class="table-para">
<span class="fixed">com.jmu.app.client</span>
</p>
</td><td class="td" align="left">
<p class="table-para">Presentation layer</p>
</td>
</tr>
<tr valign="top">
<td class="td" align="left">
<p class="table-para">
<span class="fixed">com.jmu.app.util</span>
</p>
</td><td class="td" align="left">
<p class="table-para">Architectural component layer</p>
</td>
</tr>
<tr valign="top">
<td class="td" align="left">
<p class="table-para">
<span class="fixed">com.jmu.app.deploy</span>
</p>
</td><td class="td" align="left">
<p class="table-para">Deployment layer</p>
</td>
</tr>
</tbody>
</table>
</div>
<p class="para">I use the abbreviation <span class="fixed">jmu</span> for "just made up." Also, you'll want to replace the <span class="fixed">app</span> abbreviation with a meaningful application name.</p>
<p class="para">One question I commonly hear is, why not call the data access object layer directly from the presentation layer? Although calling the data access object layer directly can save some code by eliminating a couple of layers, it means placing any business logic either in the data access object layer or the presentation layer, which makes those layers more complex. Software layering works on the premise that it's easier to solve multiple small problems than fewer large ones. Experience has taught me two lessons:</p>
<ul class="itemizedlist">
<li class="first-listitem">
<p class="first-para">Every time I try to eliminate software layers, I end up having to come back and restructure the application later.</p>
</li>
<li class="listitem">
<p class="first-para">There is tremendous value in consistency.</p>
</li>
</ul>
<p class="para">There is value in consistency for maintenance purposes. For instance, if some JSPs call data access objects directly while others work through business <a name="136"></a><a name="IDX-52"></a>objects and others use deployment wrappers, to make a change to code you're unfamiliar with you have to do an audit of the whole action sequence. This defeats the purpose of object orientation.</p>
<p class="last-para">The remainder of the chapter discusses each layer in depth and common design patterns used for each.</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="LiB0029.html"><img src="images/previous.gif" width="62" height="15" border="0" align="absmiddle" alt="Previous Section"></a>
<a href="LiB0031.html"><img src="images/next.gif" width="41" height="15" border="0" align="absmiddle" alt="Next Section"></a>
</div></td></tr></table>
</body></html>?? 快捷鍵說(shuō)明
復(fù)制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號(hào)
Ctrl + =
減小字號(hào)
Ctrl + -