外部资源的后绑定

 

　 　任何不平凡(nontrivial)  

的 J2EE 应用程序都需要访问描述它期望使用环境的信息。

这意味着开发和测试组件时，为了临时测试代码，开发人员要承担一些部署方面的职责。

 

重要的是要理解：这么做 的时候，您就走出了开发人员的领域。否则，可以试着依靠  
JDBC 

 

驱动程序，或 URL、JMS 队列名称，或者其他具有无意识的、偶尔可能是灾难性暗

示的机器资源。
　　JNDI 前来援助
　　Dolly 的问题的解决方案是从她的应用程序中清除所有对数据存储  

的 直接引用。没有

 

对 JDBC 

 —— 

驱动程序的引用，没有服务器名称，没有用户名称或口令

甚至没有数据库

池或连接管理。Dolly 需要编写代码来忽略将要访问的特定外部资源，只需要知道其他人
会提供使用这些外部资源所需的链接即可。这允许部署人员(任何处在这个角色的人)把数

 

 

据库连 接分配给 Dolly 的应用程序。Dolly 没有必要参与其中。(从数据库安全性到遵守 
Sarbanes-Oxley 法案，她都没有参与进来，她这样做也有充足的业务理由。)
　　许多开发人员知道：代码和外部资源之间的紧密耦合是潜在的问题，但是在实践中  
却经常忘记角色的划分。在小型开发工作中(指的是团队规模或部署规模)，即使忽视角色
划分也能获得成功。(

 

毕竟，如果应用程序只是个人的应用程序，而且您 不准备依靠它，

 

那么把应用程序锁定在特定的 PostgreSQL 实例上也挺好的。)
　　J2EE 

 

规范要求所有 J2EE 

 

容器都要提供 JNDI 规范的实现。JNDI   

在 J2EE 中的角色就

“

” —— 

是 交换机

J2EE 组件在运行时间接地查找其他组件、资源或服务的通用机制。在多

 

数情况下，提供 JNDI 供应者的容器可以充当有限的数据存储，这样管理员就可以设置
应 用 程 序 的 执 行 属 性 ， 并 让 其 他 应 用 程 序 引 用 这 些 属 性 (Java   管 理 扩 展 (Java 
Management Extensions，JMX)也可以用作这个目的)。JNDI   

在 J2EE 应用程序中的主

要角色就是提供间接层，这样组件就可以发现所需要的资源，而不用了解这些间接性。
　　Dolly 的情况更糟了

 

 

　 　现在我们重新来看一下 Dolly 

 

的情况。在其简单的 Web 应用程序中，她直接从应

 

用程序代码中使用了一个 JDBC 

 

连接。参见清单 1，我们可以看出，Dolly 显式地把 

JDBC 

 

驱动程序、数据库 URL 

 

以及她的用户名和口令编码到了 servlet 中：

 

　　清单 1. 典型(但是不好)  

的 JDBC 用法

1

Connection conn=

null

;

2

try

 {

3

  Class.forName("com.mysql.jdbc.Driver",

4

                

true

, Thread.currentThread().getContextClassLoader());

5

  conn=DriverManager.getConnection("jdbc:mysql://dbserver?user=dolly&password=dagger");

6

  

/*

 

use the connection here */

7

  c.close();

8

} 

9

catch

(Exception e) {

10

  e.printStackTrace();

11

} 

12

finally

 {

13

  

if

(conn!=

null

) {

14

    

try

 {