JNDI 在 J2EE 中的角色（2）

look_wt

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 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

Connection conn=null; try {   Class.forName("com.mysql.jdbc.Driver",                 true, Thread.currentThread().getContextClassLoader());   conn=DriverManager.getConnection("jdbc:mysql://dbserver?user=dolly&password=dagger");   /* use the connection here */   c.close(); } catch(Exception e) {   e.printStackTrace(); } finally {   if(conn!=null) {     try {       conn.close();     } catch(SQLException e) {}   } }

如果不用这种方式指定配置信息，Dolly（以及她的同伴们）使用 JNDI 来查找 JDBC         DataSource 会更好一些，如清单 2 所示：      
清单 2. 使用 JNDI 得到数据源

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

Connection conn=null; try {   Context ctx=new InitialContext();   Object datasourceRef=ctx.lookup("java:comp/env/jdbc/mydatasource");   DataSource ds=(Datasource)datasourceRef;   Connection c=ds.getConnection();   /* use the connection */   c.close(); } catch(Exception e) {   e.printStackTrace(); } finally {   if(conn!=null) {     try {       conn.close();     } catch(SQLException e) { }   } }

为了能够得到 JDBC 连接，首先要执行一些小的部署配置，这样我们才可以在本地组件的 JNDI 下文中查找          DataSource。这可能有点烦琐，但是很容易学。不幸的是，这意味着即使是为了测试组件，开发人员也必须涉足部署人员的领地，并且还要准备配置应用服务器。