优点： 1.程序员不用写SQL代码。写SQL很浪费时间的。 2.基于O/R Mapping可以实现domain object model 缺点： 1.complex deployment descriptors 2.reduced control over that access — 深有同感。我一向对半自动化的持久化持怀疑态度。一项数据在何时持久化，应该由程序员通过编码显式地控制。 3. 性能，尤其是批量删改的时候。 4. 迷信O/R Mapping的人往往会采用database-driven data modeling. 这会使object与relation的阻抗更大。
他说存储过程有很多好处，固执地避免存储过程，就会浪费RDBMS提供的很多很多特性；但是要注意，决不能把业务逻辑放到存储过程中，否则的话分层就会被破坏。
"Code that uses reflection is usually slower than code that uses normal Java object creation and method calls. However, this seldom matters in practice, and the gap is narrowing with each generation of JVMs. The performance difference is slight, and the overhead of reflection is usually far outweighed by the time taken by the operations …
1. 他说Method要的Visibility要尽量地窄，可以private的就不要把它public. 这有很多好处，不过我印象最深的是对重构的好处。的确，public方法越多，调用它的地方就可能越多，refactor时就要小心得多。 2. protected 只应该用于抽象方法上。如果具体的方法用了protected以让子类覆盖，那这就是一种concrete inheritance，这种感觉是很不舒服的。 3.包可见性的方法基本用不上，除了一种情形：该方法不是契约级的方法（实际上是private），但它又要进行单元测试。为了单元测试这个方法，可以把它置为包可见性，然后在同一个包下写它的单元测试类进行测试。 ——我不喜欢这种用法，但我承认它是封装性跟简单性的一个比较好的折衷。
"Static inner classes can be instantiated without the creation of an object of the enclosing type; non-static inner classes are linked to an instance of the enclosing type."
以下是我的总结： 可以有两种办法实现异步调用 1.JMS — 功能十分强大，而且可靠性很高（比如消息的持久化）。但是这个东西复杂性很高，难维护，并且有额外的性能开销。 2.另起一个线程，在新线程里执行被调用的方法，并通过Observer模式在两个线程之间通讯。– 比较简单，实现容易。但是没有JMS的附加优点，并且集群环境下很无能。
基本上，Rod Johnson 对Checked Exception没有好感，一个原因是降低代码可读性，另一个原因是大部分针对Checked Exception的catch都没有用处。 SUN认为，“checked exceptions should be the norm. Runtime exceptions indicate programming errors.” Rod说他并不完全买账，随后列举了自己的一些实践。但我觉得，他自己的实践，跟SUN的官方意见基本上是一致的： Checked Exception应该代表一种业务异常，可以视为一个方法的“第二输出”。一个典型的例子就是“系统检测到取款金额大于帐户余额”。 而Runtime Exception 应该用于代表非业务的、并且Caller没办法对付的异常。举例来说，如果一个方法检测到取款金额大于帐户余额，这个方法的调用者就应该catch这个异常，并采用相应的业务策略来处理，这类异常应该是Checked Exception；但如果一个方法仅仅是检测到数据库连不上，Caller对数据库异常也没啥办法，catch它也没有任何意义 –>既然没有意义，就不要浪费代码去处理它 –>所以干脆就把这类异常做成Runtime Exception. 但是另有一个要点就是： 对Runtime Exception一定要在方法的签名处进行注释，这样Caller才知道此方法可能会抛RuntimeException，这样它就可以自己决定是否要catch这类Exception. 因为有时从健壮性或者其他因素考虑，这种catch还是有必要的。
"The SchemaFactory class is not thread-safe. In other words, it is the application’s responsibility to ensure that at most one thread is using a SchemaFactory object at any given moment" See: http://java.sun.com/j2se/1.5.0/docs/api/javax/xml/validation/SchemaFactory.html
用jtidy. 关键语句： tidy.setXmlOut(true);
抄自Rod Johnson’s ‘Expert+One-on-One+J2EE+Design+And+Development’ 1.Mock一个DAO接口，测试时不去真正地访问数据库 2.但有时我们的确想测试一下真正的数据库操作，这是可以理解的，但要注意保证测试的可重复性。一般来说，可以这样： a.应在测试目标操作前插入一些初始数据以供测试 b.测试目标方法 c.测试目标方法之后应清空之前插入的初始数据