j2ee读书笔记

j2ee读书笔记

第七章 J2EE应用中的数据存取213

  根本不存在令人满意的 以一概全 式解决方案，除非数据访问要求是无足轻重的

1.数据存取目标213

  数据存取策略不应该决定我们怎样实现业务逻辑

2.业务逻辑与持久性逻辑214

  如果持久性管理的具体细节被转移到助手类中，从java业务对象中收集的业务规则将会被表达的更清楚，更易于维护

3.对象驱动与数据库驱动建模:一场哲学辩论214

  作者认为数据库驱动设计比较好。虽然对象驱动设计很吸引人，但有实际的危险，它的根本问题是忽略了如下事实：关系数据库是非常复杂的，以及用的非常好。认为j2ee经过几年的发展已经超过经过数十年数据库理论和实践的解决方案是幼稚而又盲目自大的

4.O/M映射与 阻抗不匹配 216

  O/R映射方案一般假设RDBMS打算在单行和单列上操作。这是一个谬误；RDBMS在元组集(就是多行操作)上操作最佳。

  O/R映射解决方案通常是OLTP(On-Line Transaction Processing，联机事务处理)系统上是一个上佳选择，因为这些系统的用户一般在小数据集上执行操作，而且这些操作常常是简单的查询。但是，O/R映射解决方案在有OLAP(On-Line Analysic Processing，联机分析处理)或数据仓库化需求的地方很少是一个上佳选择。OLAP涉及到非常大的数据集操作，这些最好用关系表来处理

5.Data Access Object(DAO)模式218

  有时，试图分开业务逻辑和持久性逻辑是行不通的和没有好处的，无论我们使用多么抽象和无论多么需要这种分离。比如：有时由于分开损失性能；强迫每个实现都使用某种O/R映射或某种值对象等。

  在这些情况下，我们应该运用安全可靠的OO设计原理--对数据存取来说也不例外。我们因该设法最大限度地减少需要混合业务逻辑与持久性逻辑的代码量，并通过把数据存取隔离到java接口背后来分开它与其它业务对象。通过单元测试编写到那些接口，而不是编写到具体类，我们将能够从全面的单元测试开始，如果我们确实需要把该应用移植到另一个持久性存储器。

6.使用关系数据库219

  不要使用存储过程来实现业务逻辑。业务逻辑应该放在java业务对象中实现。但是，存储过程是实现一个DAO的部分功能的一个合法选择

  存储过程应仅用在一个j2ee系统中以执行总是频繁地使用该数据的操作中。

  不要仅仅为了支持一个j2ee应用就降低一个关系化数据库的方式化。数据库模式有可能生存的比j2ee应用更久。

7.可移植性与性能的比较224

  实际开发中,企业更换应用服务器的可能性比较大,而更换RDBMS的可能性比较小.

  如果数据库特定技术能够提供真正的好处,比如提高性能,可以使用该特定技术

  我们应该把任何不可移植性隔离到java接口后面:可以使用DAO模式或者CMP

8.分布式应用中的数据交换226

  对于VO,应该按需要使用,不要对每个实体组件都使用VO.

  可以直接使用行集来传递数据,不过这种方法太底层了,最好在中间加上一层处理层.

9.常见的数据存取问题228

  如果EJB容器允许,应该总是以EJB方法来指定事务隔离级别.否则,你正在依赖目标服务器的默认事务隔离级别,而且已经不必要地损害了可移植性.

  事务隔离级别可以用来实施保守式加锁.可是,EJB规范根本没有提供开放式加锁支持,尽管实体组件CMP的特殊实现可以提供这种支持.

  和事务隔离级别一样,加锁在不同的数据库中也有非常大的差别.可以阅读Expert One-on-One Oracle一书

  不要试图用一种在所有数据库中可以移植的方法来生成主键,这可能会增加复杂性,而是应该使用目标数据库的相关特性.

10.何处执行数据存取

  有3种数据存取方法:1.实体EJB,2.会话EJB和助手类(DAO模式),3.不使用EJB,在业务对象种使用O/R映射工具

  不论什么原因,都不要在JSP(表现代码)中执行数据存取.

11.小节238

  数据存取的可移植性不应该作为持久层设计的首要任务,试图让持久性代码的完全可移植常常式有害的.

  一个简单,有效的持久性解决方案比一个100%可移植,但效率低下的解决方案更有生命力

第八章 使用实体组件进行数据存取

  作者认为实体组件不应作为J2EE应用中数据存取的默认选择

1.实体组件概念244

  实体组件的整个概念都存在严重问题,而且到目前为止还没有通过试验得到可靠解决:比如既然业务逻辑都在会话组件中,为什么实体需要远程接口.

  实体组件不应该不应暴露给客户软件(比如web层)

  会话组件最好通过普通java数据存取接口的一个持久性fecade来访问实体组件,若通过DAO模式来访问,以后还可以更换为别的持久化实现

  实体组件应该是一个薄层,仅仅用来持久化数据

  粗粒度对象比细粒度对象更加OO

  不用使用Composite Entity模式.在EJB2.0中,最好通过使用CMP把实体组件用于细粒度对象

  在实体组件中应只实现持久化逻辑,不要实现业务逻辑.

  在ejb-jar.xml部署描述符中将实体组件业务方法的事务属性设置为Mandatory是一个好习惯.这有助于保证实体组件得到正确使用.

  事务上下文应该由会话组件提供.

2.CMP与BMP的比较250

  不要在实体组件中使用BMP,而要从无状态会话组件中使用持久性.与使用DAO模式相比,使用BMP实体组件不会增加什么价值,知会增加复杂性.

3.EJB2.0中的实体组件252

  在EJB2.0中,决不要让实体组件有远程接口.这样确保了远程客户端通过一个实现该应用用例的会话组件来访问实体,这使实体组件带来地性能开销最小,而且不必使用VO来传递数据

  不要依靠EJB2.0CMP来保证数据地引用完整性,除非读者可以肯定绝对没有其他进程访问数据库,应该使用数据约束.

  EJB QL的缺点太多,不支持更新,一些sql函数也不可以使用,所以EJB QL基本上是不可用的.

  EJB2.0实体组件的限制:不支持开放式加锁,对批量更新支持极差,不支持被映射对象的继承性

4.实体组件的高速缓存258

  一个真正的好实体组件缓存将极大地改进实体组件的性能.但是请记住,实体组件不是唯一提供缓存的方法.JDO架构允许JDO持久性管理器提供的缓存至少和任意实体组件缓存同样完善

5.实体组件的性能262

  如果没有高效的缓存,实体组件性能可能会很差.

6.实体组件的工具支持263

  实体组件通常不含有业务逻辑,而且EJB2.0 CMP的部署描述符十分复杂, 因此,自动生成这些代码应该是一个上佳选择.

  若要使用实体组件,好的工具支持对提高工作效率是至关重要的.好的工具有:EJBGen和XDoclet

7.小节263

  实体组件的性能常常是令人失望的

  在会话组件与实体组件之间添加一个由普通java接口构成的抽象层来实现(也就是DAO接口).

  使用实体组件的指导原则:

  如果你的EJB容器仅支持EJB1.1, 不要使用实体组件

  使用CMP, 不要使用BMP

  使用ejbHome()方法来对你数据执行任何聚合操作

  使用细粒度实体组件

  不要业务逻辑放在实体组件中

  仔细研究你的EJB容器用于实体组件的加锁和缓存选项

  永远不要允许远程客户端直接访问实体组件,使用Session Facade模式:通过会话组件来协调实体组件的访问

  只给实体组件设计本地接口,不要远程接口

  在会话组件中创建VO,不要实体组件创建

 

第九章 实际的数据存取

1.数据存取技术选择266

  基于SQL技术:

  1.JDBC:可以使用一个抽象的JDBC框架来简化JDBC的使用

  2.SQLJ:这个以oracle为首的几个数据库厂商指定的规范,不过使用的不广泛

(转载自：www.dXf5.cOm 东星资源网:j2ee读书笔记)

  O/R映射技术:

  1.实体EJB:实体组件远远落后于那些最好的O/R映射框架

  2.JDO(toplink, cocobase):JDO与实体组件之间存在明显的重叠.JDO补充了J2EE和EJB(对实体组件起反作用)

 

2.JDBC的细微之处273

  可以从SQLException获得供应商相关的错误码(ErrorCode, 用getErrorCode方法获得),以及SQL相关的错误码(SQLState, 用getSQLState方法获得),不过SQLState错误码不一定得到所有的数据库实现

  SQLException.getSQLState()获得错误码是5位字符串,前两位是可移植的错误码,后3位是更具体的信息

  有可能会用到SQLWarning,这是SQLException的子类,可以用Connection.getWarnings(), Statement.getWarnings(), ResultSet.getWarnings()获得

3.一个通用的JDBC抽象框架277

 

4.在示例应用中实现DAO模式304

5.小节310

j2ee读书笔记

1.资料的所有权益归上传用户所有 2.未经权益所有人同意，不得将资料中的内容挪作商业或盈利用途 3.51CTO下载中心仅提供资料交流平台，并不对任何资料负责 4.本站资料中如有侵权或不适当内容，请邮件与我们联系（） 5.本站不保证资源的准确性、安全性和完整性, 同时也不承担用户因使用这些资料对自己和他人造成任何形式的伤害或损失

j2ee读书笔记

J 2 E E 学 习 笔 记

自 己 的 学 习 总 结

J2EE 学习笔记J2EE 基础-Servlet 和 JSP一、Web 服务器：Tomcat 的基本配置 a) JavaEE 应用常用的 Web 服务器有 WebLogic， WebSphere， Jboss， Resin， Tomcat 等。

b) JavaEE 开发过程中通常使用的 Tomcat 对 web 应用进行测试 c) Tomcat 的目录结构： webapps： 存放 web 应用程序的目录 bin： Tomcat 的运行的常用可执行文件和批处理文件，包括启动和停止 Tomcat 的命令 conf： 存放 Tomcat 配置文件的目录 work： Tomcat 的工作目录 d) Tomcat 的配置文件 server.xml 文件是 Tomcat 的服务器的基本配置文件，可以配置端口号 和虚拟目录 tomcat-users.xml 文件是 Tomcat 的用户配置文件，可以为 Tomcat 添加 用户和角色。

e) 使用 Tomcat 的 manage apps 部署 web 应用程序 f) 注意：在安装完 Tomcat 后要为配置 JAVAHOME 的系统环境变量，如果 Tomcat 服务不能正常启动，请检查 8009 和 8080 端口是否被其他进程占 用，8080 和 8009 是 Tomcat 的默认端口，如果被占用可以停止其他进程 后重新启动 Tomcat，当然也可以通过修改 server.xml 配置文件更改 Tomcat 的服务端口。

二、Java 数据库访问技术：JDBC JDBC(Java Database Connectivity) Java 连接数据库可以使用 ODBC(Open Database Connectivity)，由微软提 供的一种数据库访问技术，也可以使用厂商驱动 JDBC。本章主要介绍使用 厂商驱动的方式连接数据库，稍后还会介绍数据库连接池的使用： 针对不同的数据库，JDBC 提出了驱动程序的概念，由 JDBC 提供一个接口， 各个数据库厂商在提供可以连接该接口的数据库驱动程序。

a) JDBC 连接数据库的一般步骤（以 MySQL 为例） ： 1、 导入厂商驱动的 jar 文件 2、 使用 Class.forName(“com.mysql.jdbc.Driver”);加载厂商驱动。

（com.mysql.jdbc.Driver 为 MySQL 的厂商驱动的名字）3、 使 用 DriverManager 类 的 静 态 方 法 getConnection(url,username,password);(MySQL 的 url 是 jdbc： mysql：//localhost:3306/dbname,其中 dbname 为数据库的名字， 3306 为 mysql 数据库的服务端口默认为 3306，如果是 3306 也可省 略不写) 4、 使 用 获 取 的 Connection 对 象 创 建 StatementPreparedStatementCallableStatement 对象来执行 sql 语句。

b) JDBC 的常用 API： （JDBC 的常用的 API 在 Java.sql.*下） 1、 Connection 对象：代表数据库连接的对象，通过该对象可以创建 Statement、PreparedStatement 和 CallableStatement 对象对数据 库进行 CRUD(create,retrieve,update,delete)操作（增删改查操 作） 。Connection 对象用来开启事务。

2、 Statement 对象：主要用来执行不带参数的 sql 语句。

（不常用） 3、 PreparedStatement 对象：可以执行带参数和不带参数的 sql 语句。

（常用） 4、 CallableStatement 对象：主要用来执行存储过程。目前一般不使 用。

5、 需要注意的是执行增删改语句时使用的方法与执行查询操作时使用 的方法是不同的。执行增删改操作时使用 executeUpdate()方法， 返回值是整型，代表对数据库操作时影响了几行；执行查询操作时 使用 executeQuery()方法，返回值是 ResultSet 类型，其中存放着 从数据库中查询出来的数据。

6、 JDBC 的事务：数据库中的事务管理是为了保证数据的完整性约束； 在数据库中事务具有（ACID，Atomicity（原子性） ，Consistency （一致性） ，Isolation（隔离性） ，Durability（持久性）； ） 使用 Connection 对象开启事务。

具体操作请参照实例程序 c) 使用连接池访问数据库： （注意，配置数据库连接池时，使用 javaEE 的 JNDI(Java Naming Directory Interface,java 命名与目录接口)技术） 以 Tomcat7 为例： 首先将数据库驱动导入到 Tomcat 的 lib 目录下， 1. 在 Tomcat 的配置文件 context.xml 中添加信息： Context Resource Name=”jdbc/DBSource” Type=”javax.sql.DataSource” driverClassName=”com.mysql.jdbc.Driver” url=”jdbc:mysql://localhost:3306/comDB” username=”root” password=”root” maxActive=”50” maxIdle=”20” maxWait=”10000”/  /Context 2. 在 web 项目下的 WEB-INF 文件夹下的 web.xml 中配置以下代码： resource-ref description DBConnection /description res-ref-name jdbc/DBSource /res-ref-name res-type javax.sql.DataSource /res-type res-auth Container /res-auth /resource-ref 3. 在程序中获取数据库连接: Context jndiInit = new InitialContext(); DataSourcedb = (DataSource)jndiInit.lookup(“java:comp/env/jdbc/DBSource ”); Connection conn = db.getConnection(); 具体参照数据库连接池的配置文件！ 三、JSP 基础编程 a) JSP 的注释： 1、 HTML 注释： !-- 注释内容 -- 客户端查看源码时能够看到 2、 JSP 注释： %-注释内容 --% 不被解释和编译，不会被发送到 客户端，客户端不能看到。

3、 Java 代码注释：和 Javase 的使用一样：//注释内容 或/*注释内容 */ b) JSP 表达式、程序段和声明 1、 JSP 表达式： %= 表达式、变量或返回值 % 作用是将表达式、变量或返回值的运算结果输出到客户端的页面上。

2、 JSP 程序段： % Java 代码 % 注意不能在 JSP 程序段中定义方法。

3、 JSP 声明： %! Java 代码 % JSP 程序段的变量只能先声明后使用， JSP 声明定义的变量优先级 而 高，会优先执行。所以可以使用 JSP 声明在页面的任何地方定义变 量，而不用考虑在 JSP 程序段中使用时的先后顺序。

c) JSP 指令和动作 JSP 的指令有 page、include 和 taglib。

使用方法 %@ 指令类别 属性 1=”” 属性 2=””? % 1、page 指令用来指定字符集，编码类别，导入包，设定错误页面 2、include 指令用来在 JSP 页面中插入多个外部文件。

3、taglib 指令用来指定新的标签库。

d) JSP 的表单传值和 url 传值 1、url 传值 格式：https://websitename?arg1=abc arg2=def 访问为 https://websitename 页面时同时为 arg1 赋值为 abc； arg2 为 赋值为 def。

2、表单传值使用表单的 submit 提交数据时将表单中的元素的数据 form action= method= post input type=”submit” / /form 表单中 form 元素的 method 属性有两个值分别为 post 和 get，默认 为 get 方式。

通过 get 方式传值时与 url 传值相同， 会在浏览器地址栏里显示出来； 通过 post 方式传值时在浏览器地址栏里不会显示。

3、表单数据的获取参照下一章的内置对象。

e) 捆绑表单数据被获取为服务器端的数组。

四、JSP 内置对象 JSP 规范定义了 9 种内置对象分别为： out 对象：负责管理对客户端的输出。

request 对象：负责得到客户端的请求信息。

response 对象：负责向客户端发出响应。

session 对象：负责保存同一客户端一次会话过程中的一些信息。

application 对象：表示整个应用环境的信息。

exception 对象：表示页面上发生的异常，可以通过它获得页面异常信息。

page 对象： 表示的是当前 JSP 页面本身， 就像 Java 类定义中的 this 一样。

pageContext 对象：表示的是此 JSP 的上下文。

config 对象：表示此 JSP 的 ServletConfig。

其中用的最多的是 out、request、response、session 和 application。

out 对象的常用方法： out.println():向客户端输出数据。

resquest 对象的常用方法： resquest.getCookies():读取客户端传过来的 Cookie; resquest.getParameter():获取客户端传给服务器的参数； resquest.getParameterValues():以字符串的形式返回指点参数的所有 值。

response 对象的常用方法： response.sendRedirect():重定向页面（本节结束时将分析该方法与 JSP 动作指令 jsp:forward page=”” /jsp:forward 的区别） ； response.addCookie():向客户端写入 Cookie。

（稍后会详细讲解 Cookie 的操作） 。

session 对象常用方法： session.setAttribute(String name,Objectobj):通过该方法将一个对 象放入购物车。

session.getAttribute(String name):通过该方法从 session 中取出一 个对象； session.removeAttribute(String name):移除 session 中的某一个对象； session.invalidate():移除 session 中的全部内容； session.getId():获取 session 的 id。

注意 session 的功能非常强大，例如可以利用 session 实现购物车，保 存登录信息等等。application 对象的常用方法： application.setAttribute(): application.getAttribute(): application.removeAttribute(): 各方法的作用同 session 注意 1、 session 和 application 的区别： session 是会话级别的，只有当前客户端能访问；application 是应用程 序级别的，所有访问该应用程序的客户端都能访问。

注意 2、 response.sendRedirect()和 jsp:forward 都能将页面跳转到另一个页 面，但两者有本质的区别。

response.sendRedirect()重定向到一个新的页面时： 会刷新地址栏；且 request 对象不会与原来的页面共享；该方式不仅可以跳转到本地服务器资 源，还可以跳转到其他服务器资源。

jsp:forward 跳转到新的页面时：不会刷新地址栏；与原来的页面共享 request 对象；该方式只能在同一 web 应用程序中转发请求，属于服务器内 部跳转。

五、认识 JavaBean a) JavaBean 规范规定： a) 属性名首字母必须小写 b) 为属性定义 setter 和 getter 方法：写法为 set+属性名（属性名的 首字母要大写）和 get+属性名（属性名的首字母要大写） c) boolean 类型的 getter 方法的写法为 is+属性名（属性名的首字母 要大写） b) JSP 中使用 JavaBean 1. 使用 JSP 代码段直接实例化 JavaBean 对象,该方式和在 java 类中实例化一个对象的方法相同，不在讲解。

2. 使 用 jsp:useBean id=”” "https://img.baidu.com/img/iknow/wenku/xiaofanshentu.jpg" alt="">

78份文档

81份文档

1028988份文档