“希望簡便快捷的完成任務不等于懶惰。尤其對于那些需要經常做的事（例如實現、部署新的業務對象，或者測試一個業務方法），更應該找到簡潔的做法。”（page 14）

“研究的動機本身就會影響結果。”（page 14）

書中在第17頁到20頁對J2EE中使用代碼生成技術的種種理由及其解決辦法做了詳細的分析，我也對此談談自己的體會。

◎根據RDBMS schema生成持久對象類

Entity Bean的解耦能力的確令人不敢恭維，我在開發一個項目的時候一般都采用Hibernate ，且一般自己寫“*.hbm”配置文件，從不用工具生成，但是我會利用hbm2DDL和hbm2Java工具來生成相應的RDBMS schema和持久對象類。

對于XDoclet工具，其實是個不錯的工具，只是使用起來麻煩了一些（我本人比較懶）。

其實對于RDBMS的性能沒有做過太多的考慮，因為一直以來做的項目不是很大，數據庫的邏輯結構也很簡單，所以性能的問題幾乎不用考慮。

書中提到“自動生成的持久對象不會包含任何行為，如果手工向其中添加行為，又可能給再次執行代碼生成帶來麻煩。一個沒有行為的‘對象’是典型的反OO設計，我們很快將再次討論這個問題。”（page 17）我且看作者將會怎么解釋這個問題？

◎根據持久對象類生成DDL

◎生成DAO代碼

◎生成EJB部署描述符

◎為領域對象生成“將對象映射成XML”的代碼

◎生成用于訪問EJB的類

◎生成一整套J2EE代碼，從JSP直到entity bean（或是別的持久對象）

在此條的附注中，作者提到了Intranet數據庫管理工具，這樣的工具到是不少，可是我在想真的能通過IE來管理網絡數據庫的工具太少了，好像PHP在這方面做得還算好。

◎生成千篇一律的重復代碼，例如“管理臟數據標記”

在此復習一下“臟讀”和“臟數據”。臟讀就是指當一個事務正在訪問數據，并且對數據進行了修改，而這種修改還沒有提交到數據庫中，這時，另外一個事務也訪問這個數據，然后使用了這個數據。因為這個數據是還沒有提交的數據，那么另外一個事務讀到的這個數據是臟數據，依據臟數據所做的操作可能是不正確的。

這本書主要是在談架構，而且限定在J2EE平臺上的架構。自然就不跟微軟的.Net等架構作比較，但偶爾也會借鑒其思想之精華。書中對自主開發框架也提出了自己的看法，進行了大篇幅的闡述，總的來看是十分有道理的，但是在很多實際的項目中，我還是經常自己寫一些簡單的基礎設施，當然這些基礎設施能夠讓我的團隊很快理解并容易使用。

書中對于開發過程和開發工具沒有作過多的討論。

“除非別無選擇，否則不要容忍‘偽對象’的存在。”（page 27）

“在避免非OO的做法的同時，我們還應該盡量實踐OO的原則。” （page 27）

對于OO的討論，書中有前面的章節中確實花了不少的篇幅，還記得當初我去一家公司面試的時候，考官居然還在問我一個問題：“C跟Java有什么區別？”