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为首的几个数据库厂商指定的规范,不过使用的不广泛
  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