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开发时分两层的弊端:
数据访问层和表示层交互。展示逻辑与业务流程混合、或者业务代码与数据访问混合,编码职责不清,修改时互相影响,难以扩展和重用。
三层模式的划分:
数据访问层:提供与业务无关的数据访问操作。
业务逻辑层:根据业务需要控制执行过程,进行事务管理。
展示层:与用户交互收集数据展示结果。
表示层依赖于业务逻辑层,业务逻辑层依赖 于数据访问层。
注意*
层依赖其下层,依赖关系不跨层:
表示层不能直接访问数据访问层;
上层调用下层的结果,取决于下层的实现。
下一层不能调用上一层。
下一层不依赖上一层:
上层的改变不会影响下一层。
下层的改变会影响上一层得到的结果。
在上一层中不能出现下一层的概念:
分工明确,各司其职。