使用 AppFuse 的七个理由之二
理由 1：測試
測試是在軟件開發項目中很少被給予足夠信任的一個環節。注意我并不是說在軟件開發的一些刊物中沒有得到足夠的信任！很多文章和案例研究都給出了測試優先的開發方式和足夠的測試覆蓋面以提高軟件的質量。然而，測試通常都被看作是一件只會延長項目開發時間的事情。實際上，如果我們使用測試優先的方法在編寫代碼之前就開始撰寫測試用例，我相信我們可以發現這實際上會加速 開發速度。另外，測試優先也可以使維護和重用更加 容易。如果我們不編寫代碼來測試自己的代碼，那么就需要手工對應用程序進行測試 —— 這通常效率都不高。自動化才是關鍵。
當我們首次開始使用 AppFuse 時，我們可能需要閱讀這個項目 Web 站點上提供的快速入門指南和教程（請參看 參考資料 中的鏈接）。這些教程的編寫就是為了您可以首先編寫測試用例；它們直到編寫接口和/或實現之后才能編譯。如果您有些方面與我一樣，就會在開始編寫代碼之前就已經編寫好測試用例了；這是真正可以加速編寫代碼的惟一方式。如果您首先編寫了代碼的實現，通過某種方式驗證它可以工作，那么您可能會對自己說，“哦，看起來不錯 —— 誰需要測試呢？我還有更多的代碼需要編寫！”這種情況不幸的一面是您通常都會做一些事情 來測試自己的代碼；您簡單地跳過了可以自動化進行測試的地方。
AppFuse 的文檔展示了如何測試應用程序的所有 層次。它從數據庫層開始入手，使用了 DbUnit（請參看 參考資料）在運行測試之前提前使用數據來填充自己的數據庫。在數據訪問（DAO）層，它使用了 Spring 的 AbstractTransactionalDataSourceSpringContextTests 類（是的，這的確是一個類的名字！）來允許簡單地加載 Spring 上下文文件。另外，這個類對每個 testXXX() 方法封裝了一個事務，并當測試方法存在時進行回滾。這種特性使得測試 DAO 邏輯變得非常簡單，并且不會對數據庫中的數據造成影響。
在服務層，jMock （請參看 參考資料）用來編寫那些可以消除 DAO 依賴的真正 單元測試。這允許進行驗證業務邏輯正確的快速測試；我們不用擔心底層的持久性邏輯。
?在 Web 層，測試會驗證操作（Struts/WebWork）、控件（Spring MVC）、頁面（Tapestry）和管理 bean（JSF）如我們所期望的一樣進行工作。Spring 的 spring-mock.jar 可以非常有用地用來測試所有這些框架，因為它包含了一個 Servlet API 的仿真實現。如果沒有這個有用的庫，那么測試 AppFuse 的 Web 框架就會變得非常困難。
UI 通常是開發 Web 應用程序過程中最為困難的一部分。它也是顧客最經常抱怨的地方 —— 這既是由于它并不是非常完美，也是由于它的工作方式與我們期望的并不一樣。另外，沒有什么會比在客戶面前作演示的過程中看到看到異常堆棧更糟糕的了！您的應用程序可能會非常可怕，但是客戶可能會要求您做到十分完美。永遠不要讓這種事情發生。Canoo WebTest 可以對 UI 進行測試。它使用了 HtmlUnit 來遍歷測試 UI，驗證所有的元素都存在，并可以填充表單的域，甚至可以驗證一個假想的啟用 Ajax 的 UI 與我們預期的工作方式一樣。（有關 WebTest 和 HTMLUnit 的鏈接請參看 參考資料。）
為了進一步簡化 Web 的測試，Cargo（請參看 參考資料）對 Tomcat 的啟動和停止（分別在運行 WebTest 測試之前和之后）進行了自動化。
理由 2：集成
正如我在本文簡介中提到的一樣，很多開放源碼庫都已經預先集成到 AppFuse 中了。它們可以分為以下幾類：
- 編譯、報告和代碼生成：Ant、Ant Contrib Tasks、Checkstyle、EMMA、Java2Html、PMD 和 Rename Packages
- 測試框架：DbUnit、Dumbster、jMock、JUnit 和 Canoo WebTest
- 數據庫驅動程序：MySQL 和 PostgreSQL
- 持久性框架：Hibernate 和 iBATIS
- IoC 框架：Spring
- Web 框架：JSF、Spring MVC、Struts、Tapestry 和 WebWork
- Web 服務：XFire
- Web 工具：Clickstream、Display Tag、DWR、JSTL、SiteMesh、Struts Menu 和 URL Rewrite Filter
- Security：Acegi Security
- JavaScript 和 CSS：Scriptaculous、Prototype 和 Mike Stenhouse 的 CSS Framework
除了這些庫之外，AppFuse 還使用 Log4j 來記錄日志，使用 Velocity 來構建 e-mail 和菜單模板。Tomcat 可以支持最新的開發，我們可以使用 1.4 或 5 版本的 Java 平臺來編譯或構建程序。我們應該可以將 AppFuse 部署到任何 J2EE 1.3 兼容的應用服務器上；這已經經過了測試，我們知道它在所有主要版本的 J2EE 服務器和所有主要的 servlet 容器上都可以很好地工作。
圖 3 給出了上面創建的 devworks 項目的 lib 目錄。這個目錄中的 lib.properties 文件控制了每個依賴性的版本號，這意味著我們可以簡單地通過把這些包的新版本放到這個目錄中并執行諸如 ant test-all -Dspring.version=2.0 之類的命令來測試這些包的新版本。
圖 3. 項目依賴性
預先集成這些開放源碼庫可以在項目之初極大地提高生產效率。盡管我們可以找到很多文檔介紹如何集成這些庫，但是定制工作示例并簡單地使用它來開發應用程序要更加簡單。
除了可以簡化 Web 應用程序的開發之外，AppFuse 讓我們還可以將 Web 服務簡單地集成到自己的項目中。盡管 XFire 也在 AppFuse 下載中一起提供了，不過如果我們希望，也可以自己集成 Apache Axis（請參看 參考資料 中有關 Axis 集成的教程）。另外，Spring 框架和 XFire 可以一起將服務層作為 Web 服務非常簡單地呈現出來，這就為我們提供了開發面向服務架構的能力。
另外，AppFuse 并不會將我們限定到任何特定的 API 上。它只是簡單地對可用的最佳開放源碼解決方案重新進行打包和預先集成。AppFuse 中的代碼可以處理這種集成，并實現了 AppFuse 的基本安全性和可用性特性。只要可能，就會減少代碼，以便向 AppFuse 的依賴框架添加一個特性。例如，AppFuse 自帶的 Remember Me 和 SSL 切換特性最近就因為類似的特性而從 Acegi Security 中刪除了。
理由 3：自動化
Ant 使得簡化了從編譯到構建再到部署的自動化過程。Ant 是 AppFuse 中的一等公民，這主要是因為我發現在命令行中執行操作比從 IDE 中更加簡單。我們可以使用 Ant 實現編譯、測試、部署和執行任何代碼生成的任務。
盡管這種能力對于有些人來說非常重要，但是它并不適用于所有的人。很多 AppFuse 用戶目前都使用 Eclipse 或 Intellij IDEA 來構建和測試自己的項目。在這些 IDE 中運行 Ant 的確可以工作，但是這樣做的效率通常都不如使用 IDE 內置的 JUnit 支持來運行測試效率高。
幸運的是，AppFuse 支持在 IDE 中運行測試，不過管理這種特性對于 AppFuse 開發人員來說就變得非常困難了。最大的痛苦在于 XDoclet 用來生成 Hibernate 映射文件和 Web 框架所使用的一些工件（例如 ActionForms 和 Struts 使用的 struts-config.xml）。IDE 并不知道需要生成的代碼，除非我們配置使用 Ant 來編譯它們，或者安裝了一些可以認識 XDoclet 的插件。
這種對知識的缺乏是 AppFuse 2.0 切換到 JDK 5 和 Maven 2 上的主要原因。JDK 5、注釋和 Struts 2 將讓我們可以擺脫 XDoclet。Maven 2 將使用這些生成的文件和動態類路徑來生成 IDE 項目文件，這樣對項目的管理就可以進行簡化。目前基于 Ant 的編譯系統已經為不同的層次生成了一些工件（包括 dao.jar、service.jar 和 webapp.war），因此切換到 Maven 的模型上應該是一個非常自然的調整。
除了 Ant 之外（它對于編譯、測試、部署和報告具有豐富的支持），對于 CruiseControl 的支持也構建到了 AppFuse 中。CruiseControl 是一個 Continuous Integration 應用程序，讓我們可以在源代碼倉庫中代碼發生變化時自動運行所有的測試。extras/cruisecontrol 目錄包含了我們為基于 AppFuse 的項目快速、簡單地設置 Continuous Integration 時所需要的文件。
設置 Continuous Integration 是軟件開發周期中我們首先要做的事情之一。它不但激發程序員去編寫測試用例，而且還通過 “You broke the build!” 游戲促進了團隊之間的合作和融合。
理由 4：安全特性和可擴展性
AppFuse 最初是作為我為 Apress 編寫的書籍 Pro JSP 中示例應用程序的一部分開發的。這個示例應用程序展示了很多安全特性和用于簡化 Struts 開發的特性。這個應用程序中的很多安全特性在 J2EE 的安全框圖中都不存在。使用容器管理認證（CMA）的認證方法非常簡單，但是 Remember Me、密碼提示、SSL 切換、登記和用戶管理等功能卻都不存在。另外，基于角色的保護方法功能在非 EJB 環境中也是不可能的。
最初，AppFuse 使用自己的代碼和用于 CMA 的解決方案完全實現了這些特性。我在 2004 年年初開始學習 Spring 時就聽說過有關 Acegi Security 的知識。我對 Acegi 所需要的 XML 的行數（175）與 web.xml 中所需要的 CMA 的行數（20）進行了比較，很快就決定丟棄 Acegi 了，因為它太過復雜了。
一年半之后 —— 在為另外一本書 Spring Live 中編寫了一章有關使用 Acegi Security 的內容之后 —— 我就改變了自己的想法。Acegi 的確（目前仍然）需要很多 XML，但是一旦我們理解了這一點，它實際上是相當簡單的。當我們最終作出改變，使用 Acegi Security 的特性來全部取代 AppFuse 的特性之后，我們最終刪除了大量的代碼。類之上的類都已經沒有了，“Acegi handles that now” 中消失的部分現在全部進入了 CVS 的 Attic 中了。
Acegi Security 是 J2EE 安全模型中曾經出現過的最好模型。它讓我們可以實現很多有用的特性，這些特性在 Servlet API 的安全模型中都不存在：認證、授權、角色保護方法、Remember Me、密碼加密、SSL 切換、用戶切換和注銷。它讓我們還可以將用戶證書存儲到 XML 文件、數據庫、LDAP 或單點登錄系統（例如 Yale 的 Central Authentication Service (CAS) 或者 SiteMinder）中。
AppFuse 對很多與安全性相關的特性的實現從一開始都是非常優秀的。現在 AppFuse 使用了 Acegi Security，這些特性 —— 以及更多特性 —— 都非常容易實現。Acegi 有很多地方都可以進行擴充：這是它使用巨大的 XML 配置文件的原因。正如我們已經通過去年的課程對 Acegi 進行集成一樣，我們已經發現對很多 bean 的定義進行定制可以更加緊密地與 AppFuse 建立聯系。
Spring IoC 容器和 Acegi Security 所提供的簡單開發、容易測試的代碼和松耦合特性的組合是 AppFuse 是這么好的一種開發平臺的主要原因。這些框架都是不可插入的，允許生成干凈的可測試代碼。AppFuse 集成了很多開放源碼項目，依賴注入允許對應用程序層進行簡單的集成。
理由 5：使用 AppGen 生成代碼
有些人會將代碼生成稱為代碼氣味的散播（code smell）。在他們的觀點中，如果我們需要生成代碼，那么很可能就會做一些錯事。我傾向于這種確定自己代碼使用的模式和自動化生成代碼的能力應該稱為代碼香味的彌漫（code perfume）。如果我們正在編寫類似的 DAO、管理器、操作或控件，并且不想為它們生成代碼，那么這就需要根據代碼的氣味來生成代碼。當然，當語言可以為我們提供可以簡化任務的特性時，一切都是那么美好；不過代碼生成通常都是一個必需 —— 通常其生產率也非常高 —— 的任務。
AppFuse 中提供了一個基于 Ant 和 XDoclet 的代碼生成工具，名叫 AppGen。默認情況下，常見的 DAO 和管理器都可以允許我們對任何普通老式 Java 對象（POJO）進行 CRUD 操作，但是在 Web 層上這樣做有些困難。AppGen 有幾個特性可以用來執行以下任務：
- （使用 Middlegen 和 Hibernate 工具）從數據庫表中生成 POJO
- 從 POJO 生成 UI
- 為 DAO、管理器、操作/控制器和 UI 生成測試
在運行 AppGen 時，您會看到提示說 AppGen 要從數據庫表或 POJO 中生成代碼。如果在命令行中執行 ant install-detailed，AppGen 就會安裝 POJO 特定的 DAO、管理器以及它們的測試。運行 ant install 會導致 Web 層的類重用通用的 DAO 和默認存在的管理器。
為了闡述 AppGen 是如何工作的，我們在 devworks MySQL 數據庫中創建了如清單 2 所示的表：
清單 2. 創建一個名為 cat 的數據庫表
| create table cat (cat_id int(8) auto_increment,color varchar(20) not null,name varchar(20) not null,created_date datetime not null,primary key (cat_id)) type=InnoDB; |
在 extras/appgen 目錄中，運行 ant install-detailed。這個命令的輸出結果對于本文來說實在太長了，不過我們在清單 3 中給出了第一部分的內容：
清單 3. 運行 AppGen 的 install-detailed 目標
| $ ant install-detailed Buildfile: build.xmlinit:[mkdir] Created dir: /Users/mraible/Work/devworks/extras/appgen/build[echo] [echo] +-------------------------------------------------------+[echo] | -- Welcome to the AppGen! -- |[echo] | |[echo] | Use the "install" target to use the generic DAO and |[echo] | Manager, or use "install-detailed" to general a DAO |[echo] | and Manager specifically for your model object. |[echo] +-------------------------------------------------------+[input] Would you like to generate code from a table or POJO? (table,pojo) table[input] What is the name of your table (i.e. person)? cat[input] What is the name, if any, of the module for your table (i.e. organization)?[echo] Running Middlegen to generate POJO... |
要對 cat 表使用這個新生成的代碼，我們需要修改 src/dao/com/ibm/dao/hibernate/applicationContext-hibernate.xml，來為 Hibernate 添加 Cat.hbm.xml 映射文件。清單 3 給出了我們修改后的 sessionFactory bean 的樣子：
清單 4. 將 Cat.hbm.xml 添加到 sessionFactory bean 中
| <bean id="sessionFactory" class="..."><property name="dataSource" ref="dataSource"/><property name="mappingResources"><list><value>com/ibm/model/Role.hbm.xml</value><value>com/ibm/model/User.hbm.xml</value><value>com/ibm/model/Cat.hbm.xml</value></list></property>... </bean> |
在運行 ant setup deploy 之后，我們就應該可以在部署的應用程序中對 cat 表執行 CRUD 操作了：
圖 4. Cat 列表
圖 5. Cat 表單
我們在上面的屏幕快照中看到的記錄都是作為代碼生成的一部分創建的，因此現在就有測試數據了。
理由 6：文檔
我們可以找到 AppFuse 各個風味的教程，并且它們都以 6 種不同的語言給出了：中文、德語、英語、韓語、葡萄牙語和西班牙語。使用風味（flavor） 一詞，我的意思是不同框架的組合，例如 Spring MVC 加上 iBATIS、Spring MVC 加上 Hibernate 或 JSF 加上 Hibernate。使用這 5 種 Web 框架和兩種持久框架，可以有好幾種組合。有關它們的翻譯，AppFuse 為自己的默認特性提供了 8 種翻譯。可用語言包括中文、荷蘭語、德語、英語、法語、意大利語、葡萄牙語和西班牙語。
除了核心教程之外，還添加了很多教程（請參看 參考資料） 來介紹與各種數據庫、應用服務器和其他開放源碼技術（包括 JasperReports、Lucene、Eclipse、Drools、Axis 和 DWR）的集成。
理由 7：社區
Apache 軟件基金會對于開放源碼有一個有趣的看法。它對圍繞開放源碼項目開發一個開放源碼社區最感興趣。它的成員相信如果社區非常強大，那么產生高質量的代碼就是一個自然的過程。下面的內容引自 Apache 主頁：
“我們認為自己不僅僅是一組共享服務器的項目，而且是一個開發人員和用戶的社區。”AppFuse 社區從 2003 年作為 SourceForge 上的一個項目（是 struts.sf.net 的一部分）啟動以來，已經獲得了極大的增長。通過在 2004 年 3 月轉換到 java.net 上之后，它已經成為這里一個非常流行的項目，從 2005 年 1 月到 3 月成為訪問量最多的一個項目。目前它仍然是一個非常流行的項目（有關 java.net 項目統計信息的鏈接，請參看 參考資料），不過在這個站點上它正在讓位于 Sun 贊助的很多項目。
在 2004 年年末，Nathan Anderson 成為繼我之后第一個提交者。此后有很多人都加入了進來，包括 Ben Gill、David Carter、Mika G?ckel、Sanjiv Jivan 和 Thomas Gaudin。很多現有的提交者都已經通過各種方式作出了自己的貢獻，他們都幫助 AppFuse 社區成為一個迅速變化并且非常有趣的地方。
郵件列表非常友好，我們試圖維護這樣一條承諾 “沒有問題是沒有人理會的問題”。我們的郵件列表歸檔文件中惟一一條 “RTFM” 是從用戶那里發出的，而不是從開發者那里發出的。我們絕對信奉 Apache 開放源碼社區的哲學。引用我最好的朋友 Bruce Snyder 的一句話，“我們為代碼而來，為人們而留下”。目前，大部分開發者都是用戶，我們通常都喜歡有一段美妙的時間。另外，大部分文檔都是由社區編寫的；因此，這個社區的知識是非常淵博的。
結束語
我們應該嘗試使用 AppFuse 進行開發，這是因為它允許我們簡單地進行測試、集成、自動化，并可以安全地生成 Web 應用程序。其文檔非常豐富，社區也非常友好。隨著其支撐框架越來越好，AppFuse 也將不斷改進。
從 AppFuse 2.0 開始，我們計劃遷移到 JDK 5（仍然支持部署到 1.4）和 Maven 2 上去。這些工具可以簡化使用 AppFuse 的開發、安裝和升級。我們計劃充分利用 Maven 2 的功能來處理相關依賴性。我們將碰到諸如 appfuse-hibernate-2.0.jar 和 appfuse-jsf-2.0.jar 之類的工件。這些工件都可以在 pom.xml 文件中進行引用，它們負責提取其他相關依賴性。除了在自己的項目中使用 AppFuse 基類之外，我們還可以像普通的框架一樣在 JAR 中對這些類簡單地進行擴展，這應該會大大簡化它的升級過程，并鼓勵更多用戶將自己希望的改進提交到這個項目中。
如果沒有其他問題，使用 AppFuse 可以讓您始終處于 Java Web 開發的技術前沿上 —— 就像我們一樣！
參考資料
學習
- 您可以參閱本文在 developerWorks 全球站點上的 英文原文 。
- AppFuse：該項目的主頁。
- AppFuse Demos：查看演示和視頻。
- Struts 2 和 JSF：了解為什么要將這些技術放到一起工作。
- Sun 的 J2EE 項目目錄結構指南：AppFuse 非常接近于這些指南。
- Maven 的 Standard Directory Layout：AppFuse 2.0 將轉換到這個目錄結構上。
- AppFuse 快速入門指南：快速入門并使用 AppFuse。
- AppFuse 教程：深入學習更多有關使用 AppFuse 的知識。
- Apache Axis 集成：如何將 Apache Axis 集成到自己的 AppFuse 項目中。
- Java.net 項目狀態：請查看 2005 年 1 月、2 月 和 3 月 的動態。還可以查看 java.net 上的最佳項目 。
獲得產品和技術
- AppFuse on java.net：下載不同風味的 AppFuse。
- WebWork：了解這個易于使用的 Web 框架。
- DbUnit：查看更多有關 JUnit 擴展的內容。
- jMock：創建動態仿真對象來簡化真正的單元測試。
- Canoo WebTest：自動化 Web 應用程序的 UI 測試。
- HtmlUnit：WebTest 的優秀 JavaScript 支持背后的基礎。
- Cargo：自動啟動和停止容器。
- Greenbox：一種代碼生成框架。
討論
- AppFuse 論壇：與同行開發人員交流技巧。
?
總結
以上是生活随笔為你收集整理的使用 AppFuse 的七个理由之二的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： web扫描器之Nessus
- 下一篇： DL2 - Improving Deep