📄 lib0091.html
字号:
<html>
<META http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<head>
<title>Business Object Coding Guidelines</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="LiB0090.html"><img src="images/previous.gif" width="62" height="15" border="0" align="absmiddle" alt="Previous Section"></a>
<a href="LiB0092.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="ch13"></a>
<div class="section">
<h2 class="first-section-title"><a name="441"></a><a name="ch13lev1sec2"></a>Business Object Coding Guidelines</h2><p class="first-para">
<b class="bold">Never put anything deployment specific in an object in the business logic</b> <b class="bold">layer.</b> Business objects should be reusable in any deployment without changes. This insulates business logic from changes and developments in the deployment layer, which changes more rapidly than anything else. In the few years that Java has existed, an increasing number of distributed applications have used enterprise beans rather than CORBA. Over the past couple of years, Web services and message-driven beans have replaced entity beans. If you think J2EE and enterprise beans are the last programming evolution, remember the lesson of the Year 2000 problem: your code will probably live longer than you expect.</p>
<p class="para">Many J2EE books guide you toward incorporating business logic directly into enterprise beans. I don't subscribe to that view because of the rapid pace at which deployment methodologies have changed over the years. Entity beans, if you use them, will have to be an exception. Use of entity beans definitely limits how your application can be deployed.</p>
<p class="para">
<b class="bold">Always accept environment resources as arguments on construction.</b> This includes <span class="fixed">TransactionContext</span> and any additional JNDI resources. This advice is guided by the principle of keeping business logic deployment generic. It also tends to reduce complexity in the business logic layer. To simplify passing in commonly used resources, I usually extend <span class="fixed">BusinessLogicObject</span> from CementJ (package <span class="fixed">org.cementj.base</span>) for business objects, as illustrated in <a href="LiB0090.html#438" target="_parent" class="chapterjump">listing 13.2</a>.</p>
<p class="para">
<b class="bold">All public methods should explicitly validate the arguments.</b> If you don't, you run a significant risk of generating a derivative exception, such as a <a name="442"></a><a name="IDX-181"></a><span class="fixed">NullPointerException</span>, which can take longer to debug and fix. If you generate an <span class="fixed">IllegalArgumentException</span> with a clear message, programming errors in the deployment layer or within business objects that call you will have a better chance at being caught in unit testing.</p>
<p class="para">
<b class="bold">Record the argument values in any generated exception.</b> This practice makes internal system errors easier to replicate, thus easier to debug and fix. This is especially true if you've kept the business logic layer deployment generic and locally debuggable. Because most arguments are value objects, you can use the <span class="fixed">describe()</span> method (if the value objects implement <span class="fixed">Describable</span>) to do this quite easily. <a href="LiB0090.html#438" target="_parent" class="chapterjump">Listing 13.2</a> illustrates this practice.</p>
<p class="para">A possible concern with catching <span class="fixed">Throwable</span> is losing information contained within the root exception. However, the original exception and stack trace can be retained if your application exceptions extend either <span class="fixed">ApplicationException</span> or <span class="fixed">ApplicationRuntimeException</span> from CementJ or use the chained exception feature found in version 1.4 and above of the JDK.</p>
<p class="para">Another common concern centers on the assumption that application code could not possibly be equipped to handle some of the exceptions that could get caught (e.g., <span class="fixed">OutOfMemmoryError</span> or <span class="fixed">ClassDefNotFoundError</span>). I argue that recording the circumstances and context surrounding such an error is necessary if developers are going to fix the problem. Recording these types of errors should not be left to chance. <a href="LiB0111.html#536" target="_parent" class="chapterjump">Chapter 17</a> provides a more extensive discussion of exception-handling practices and recommendations.</p>
<p class="para">
<b class="bold">Any method that creates a database connection should close it in a finally</b> <b class="bold">block.</b> If it doesn't, it will create a common problem for J2EE environments called a connection leak. A <b class="bold">connection leak</b> is a database connection that has been created but will never be closed. Most J2EE containers manage database connections by using connection pools. Connection pools are often configured to have a maximum size. If an application has allocated its maximum size, other users will err out. Thus a connection leak could inadvertently cause an error for another user. Also, connection leaks unnecessarily take up resources in the database server, as illustrated in <a href="LiB0090.html#438" target="_parent" class="chapterjump">listing 13.2</a>.</p>
<p class="para">
<b class="bold">Code test cases for all public methods of business objects and put the</b> <b class="bold">code in the regression test suite.</b> All business objects can and should be testable individually. I like to put them in a regression test suite so that they can be easily run before new releases. I use JUnit for testing (<a target="_top" class="url" href="http://www.junit.org">http://www.junit.org</a>). It's open source and easy to use.</p>
<a name="443"></a><a name="IDX-182"></a>
<p class="last-para">
<b class="bold">Avoid using patterns not documented in one of the reputable pattern texts. </b>I normally try to encourage creativity. However, at this point, hundreds of patterns have been identified and documented. The odds that you will encounter a requirement in a business application that isn't satisfied or addressed by at least one of the documented patterns is remote. As a reminder, I've listed several commonly used patterns in <a href="LiB0030.html#129" target="_parent" class="chapterjump">chapter 5</a>.</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="LiB0090.html"><img src="images/previous.gif" width="62" height="15" border="0" align="absmiddle" alt="Previous Section"></a>
<a href="LiB0092.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 + -