JNDI
JNDI(Java Naming and Directory Interface,Java命名和目录接口)JNDI提供统一的客户端API，通过不同的访问提供者接口JNDI服务供应接口(SPI)的实现，通过名称将资源与服务进行关联。现在JNDI已经成为J2EE的标准之一，所有的J2EE容器都必须提供一个JNDI的服务。
JNDI作用和优点
包含了大量的命名和目录服务，使用通用接口来访问不同种类的服务；
可以同时连接到多个命名或目录服务上；
在应用与Java对象或资源之间建立松耦合的逻辑关联，简化应用对于资源的配置及维护工作。
可以在可以在更大范围、不同应用之间共享资源，JNDI独立于目录服务的具体实现，只要有目录的服务提供接口（或驱动），就可以使用目录。只需要确认要使用的每一个命名或目录服务都有服务提供者。
应用步骤
1.修改Tomcatconfcontext.xml文件
<Context>
<Environment name="填什么都行" value="填什么都行" type="java.lang.String"/>
</Context>
<!-- type中写完整的类型 -->
2.使用lookup()进行查找
// javax.naming.Context提供了查找JNDI 的接口
Context ctx;
try{
ctx = new InitialContext();
// java:comp/env/为前缀
DataSource ds=(DataSource)ctx.lookup("java:comp/env/jdbc/test");
cont=ds.getConnection();
} catch (NamingException e) {
e.printStackTrace();
} catch (SQLException e) {
e.printStackTrace();
}
连接池
为什么使用连接池
传统数据库连接方式的不足
需要经常与数据库建立连接，在访问结束后必须关闭连接释放资源。
当并发访问数量较大时，执行速度受到极大影响。(执行速度很重要！)
系统的安全性和稳定性相对较差。
连接池的优点
1.资源复用性高。
2.更快的执行效率。
3.统一的连接管理，避免数据库连接泄漏。
（1）建立数据库连接池对象（服务器启动）
（2）按照事先指定的参数创建初始数量的数据库连接（即：空闲连接数）。
（3）对一个数据库访问请求，从连接池拿一个连接。如果连接池对象中没有空闲的连接，没有到达最大活跃连接数，那么创建一个新的连接。
（4）存取数据库
（5）关闭数据库连接，非真正关闭，是将其放入空闲队列中。
（6）服务器停止、维护期间，释放数据库连接池对象，并释放所有连接。
数据源(DataSource)
javax.sql.DataSource接口：
负责管理与数据库的连接；
从Tomcat的数据源获得连接；
以连接池的形式对数据库连接进行管理。
获取DataSource
数据源由Tomcat提供，不能再程序中创建实例；使用JNDI获得DataSource引用。
访问数据源
<Context>
<Resource name="jdbc/text" auth="Container" type="javax.sql.DataSource"
maxActive="100" maxIdle="30" maxWait="10000" username="root" password="root"
driverClassName="com.mysql.jdbc.Driver" url="jdbc:mysql:// 本地 :3306/cookie?
useUnicode=true&characterEncoding=utf-8"/>
</Context>
配置web.xml文件
<resource-ref>
<!--指定JNDI的名字，与<Resource>元素中的name一致 -->
<res-ref-name>jdbc/news</res-ref-name>
<!-- 指定引用资源的类名，与<Resource>元素中的type一致-->
<res-type>javax.sql.DataSource</res-type>
<!--指定管理所引用资源的Manager与<Resource>元素中的auth一致 -->
<res-auth>Container</res-auth>
</resource-ref>
为什么需要分层
JSP开发时分两层的弊端：
数据访问层和表示层交互。展示逻辑与业务流程混合、或者业务代码与数据访问混合，编码职责不清，修改时互相影响，难以扩展和重用。
三层模式的划分：
数据访问层：提供与业务无关的数据访问操作。
业务逻辑层：根据业务需要控制执行过程，进行事务管理。
展示层：与用户交互收集数据展示结果。
表示层依赖于业务逻辑层，业务逻辑层依赖 于数据访问层。
注意*
层依赖其下层，依赖关系不跨层：
表示层不能直接访问数据访问层；
上层调用下层的结果，取决于下层的实现。
下一层不能调用上一层。
下一层不依赖上一层：
上层的改变不会影响下一层。
下层的改变会影响上一层得到的结果。
在上一层中不能出现下一层的概念：
分工明确，各司其职。