依賴註入
最新壹代容器稱為輕量級容器，它們使用壹個***同設計原理：依賴註入。 對這個簡單思想來說，這是壹個復雜的術語。依賴註入讓您將對象和它所依賴的東西交給第三方。然後第三方創建所有對象並將它們綁在壹起。比方說，稱為 myDao 的數據訪問對象需要壹個稱為 ds 的數據源。那麽該容器會壹同創建它們，並設置壹個屬性：
清單 1. 創建壹個第三方匯編程序
myDao = new Dao();
ds = new DataSource();
myDao.setDataSource(ds);
當然，不創建這種第三方匯編程序的話，您也可以使用框架來做其他附加的工作（如提供配置支持）。Spring 框架、Pico 和 HiveMind 就扮演了這個角色。其他像 JavaServer Faces(JSF) 框架也利用了依賴註入。
面向對象編程
使用面向方面編程（AOP），您可以編寫通用的功能性模塊（稱為方面） —— 例如，日誌、事務、安全或持久性。AOP 使您可以將這些方面聯系到 POJO，然後指定壹個時間點（如方法開始時或產生異常時）和另壹個需要聯系的方面。例如，您可能想要創建壹個外觀事務對象。您可以在調用方法時將 TransactionBegin 方面關聯到外觀方法。然後在產生異常時將 RollBack 方面關聯到外觀的異常。最後，在方法結束時將 Commit 方面關聯到外觀的方法。您在配置中完成這些工作，而不是通過編寫代碼。依靠這種能力，您可以創建壹個簡單的 POJO 事務、安全或遠程訪問。
您現在已經得到了關於 POJO 的聲明性事務，這對企業應用程序非常有用。使用這些工具，您可以完全放棄 EJB，或者最小化它的作用。而這正是輕量級組件所要做的。
透明持久性
持久性也是建立在較簡單的編程模型之上。透明持久性框架通過配置而不是編寫代碼，來使您為應用程序添加持久性。因為大多數應用程序是面向對象的，並且訪問壹個關系數據庫，所以壹些專家斷言，我們最終將進入對象關系映射的時代。我目前發現的頂級持久性解決方案是 SolarMetric 的 Kodo JDO 和 Hibernate。在後面的文章中我將詳細比較這些解決方案。其他輕量級解決方案，例如 iBATIS 和 Active Record 設計模式，根本不會試圖進行對象關系映射。 Java 行業經歷了類似的情況。EJB 技術提供了核心的企業服務。如果您曾對壹個復雜的、基於組件的模型編程，您會將業務組件放入壹個容器中，該容器提供諸如事務、遠程控制、安全和持久性之類的服務。
然而，這裏存在壹些開銷。重量級架構對於解決許多問題都過於復雜。例如，實體 bean 會讓您為每個實體編寫 7 個文件。因此 EJB 技術就不值得用來解決日常問題。如今，許多業務仍然需要企業服務，但它們正在尋找達到該目標的新方向。它們使用輕量級容器。實際上，最新的 EJB V3.0 標準就使用了輕量級容器模型。
什麽是輕量級容器？
大多數容器 API（如 EJB API）強迫您編寫壹些接口或壹個組件模型。將您的組件放入該容器後，容器會為您處理壹些事情。EJB 容器提供企業服務。Servlet 容器（例如 Apache Jakarta Tomcat）實現了 Servlet API，使您可以將動態內容建立到服務器頁面中，該頁面隨後會被發送到 Web 瀏覽器。
傳統容器強迫使用指定的編程模型，輕量級容器則不是。它們使用普通 Java 對象（plain old Java object，POJO）。容器然後將 POJO 綁在壹起，並將服務與它們相關聯。 Spring 是什麽？
您若是壹名企業程序開發人員，Spring 會令您事半功倍。但它到底是什麽？對於這樣的綜合性框架，很難輕易找到壹個明確的答案。從本質上講，Spring 是壹個輕量級容器。您可以通過 Spring 來利用普通 Java? 對象（POJO）編程，使用依賴註入解析 POJO 間的依賴性，然後使用面向方面編程（AOP）將服務與它們相關聯。
Spring 也提供了許多膠水代碼，這使您可以更加輕松地使用 Java 2 平臺企業版（J2EE）服務，比如用於事務的 Java 事務 API （JTA）、用於遠程控制的遠程方法調用（RMI）、用於管理的 Java 管理擴展（JMX）或用於持久性的 Java 數據對象（JDO）。Spring 還為開放源碼框架，比如 Hibernate、Tapestry、Struts 和 JavaServer Faces（JSF），提供了膠水代碼。註意，雖然有些框架是相互競爭的，但這並不是什麽問題，Spring 沒有試圖只支持壹種獲勝的框架。 本文介紹合力完成壹種不同的活動：應用程序開發。敏捷開發流程，比如極限編程（Extreme Programming，XP）和 Scrum，尋求降低流程開銷。盡管存在許多不同的流程，但它們當中都有壹些***同的趨勢：
越來越重視客戶參與，而非重量級需求文檔
通過重構改進質量和設計；重的、自動化的單位測試；連續集成
小團隊，較少的正式溝通和更多的非正式溝通（15 分鐘的站立早會，更多的配對編程）
短而壹致的周期，最後是客戶反饋
敏捷方法剔除了不需要的流程，直到只留下完成工作所必需的流程。盡管許多編程人員理解輕量級、敏捷方法的強大功能，但許多管理人員習慣使用更傳統的流程。如果您認為敏捷可以幫助您，那麽通過應用下列思想來學習如何協調傳統管理與敏捷開發流程：
將您使用的語言改為側重於原則，而非流程。
創建小而靈巧的團隊。
重視可測量的交付。
重視簡約性。
重構代碼並自動化測試。
獲得客戶反饋。
原則而非教條
當編程人員或架構師試圖將敏捷流程註入保守公司時，最好是拋開教條 —— 即，將重點放在原則而非教條上。如果您對 XP 的優點大肆吹噓 10 分鐘，典型的老板會關註壹個詞 極限。因為老板關註的是減輕風險，所以您註定失敗。相反，您可以挑選壹些您的管理層想要解決的問題。然後，選擇敏捷原則來幫助解決這些問題。 本文介紹合力完成壹種不同的活動：應用程序開發。敏捷開發流程，比如極限編程（Extreme Programming，XP）和 Scrum，尋求降低流程開銷。盡管存在許多不同的流程，但它們當中都有壹些***同的趨勢：
越來越重視客戶參與，而非重量級需求文檔
通過重構改進質量和設計；重的、自動化的單位測試；連續集成
小團隊，較少的正式溝通和更多的非正式溝通（15 分鐘的站立早會，更多的配對編程）
短而壹致的周期，最後是客戶反饋
敏捷方法剔除了不需要的流程，直到只留下完成工作所必需的流程。盡管許多編程人員理解輕量級、敏捷方法的強大功能，但許多管理人員習慣使用更傳統的流程。如果您認為敏捷可以幫助您，那麽通過應用下列思想來學習如何協調傳統管理與敏捷開發流程：
將您使用的語言改為側重於原則，而非流程。
創建小而靈巧的團隊。
重視可測量的交付。
重視簡約性。
重構代碼並自動化測試。
獲得客戶反饋。
原則而非教條
當編程人員或架構師試圖將敏捷流程註入保守公司時，最好是拋開教條 —— 即，將重點放在原則而非教條上。如果您對 XP 的優點大肆吹噓 10 分鐘，典型的老板會關註壹個詞 極限。因為老板關註的是減輕風險，所以您註定失敗。相反，您可以挑選壹些您的管理層想要解決的問題。然後，選擇敏捷原則來幫助解決這些問題。 選擇合適的工具
對於帶 i-drive（它投入更多的力量到踏板曲柄而不是彈起的後避震）的山地自行車、低容量的皮劃艇（它讓我使用河面下的水流）和框架，我有著相似的經歷。當我的客戶處理持久性時，為他們找到合適的框架可以把壹個艱難掙紮的、沮喪的團隊轉變為壹個運轉良好的機器。但是，您必須小心。改變框架可能是昂貴的。本系列的 第 3 部分 展示了 Spring 如何幫助您優化諸如持久性（persistence）之類的服務。本文則關註尋找合適的持久性框架。首先，讓我來破除幾個神話。
神話 1：技術總是最要緊的。
不論您是在談論 RDBMS 還是持久性框架，持久關系都是長期的。您需要知道您選擇的方案將長時間擁有市場份額。如果不是，您將冒著被迫離開指定框架的風險，而這並非您的意願。
神話 2：對象關系映射程序（Object Relational Mappers，ORM）隱藏了所有的數據庫問題。
持久性框架簡化了壹些問題，但引入了壹些其他的問題。如果您不理解底層架構，那麽找懂的人問，或者不要使用對象關系框架。
神話 3：JDBC 總是比 ORM 要快。
當然了，壹個非常協調的特定 Java 實現總是會打敗普通的 ORM，但是您很難找到壹個非常協調的 JDBC 應用程序。JDO 和 Hibernate 之類的框架提供許多方法來提升性能。
神話 4：ORM 總是合適的工具。
常常，您會發現要求更好的訪問 SQL 的問題。您也會發現面向批處理的而非交互式的問題，或要求直接訪問數據庫行，而非完整的對象模型。這些問題並沒有充分利用 ORM。更糟糕的是，壹些解決方案也許會礙事。 在給 Java 技術飛艇戳幾個洞之前，我應該提醒您壹點兒歷史。Java 編程語言來自壹個沒有希望的來源（Sun Microsystems），為了與控制服務器端的統治語言（C++）競爭，那時壹個程序設計範例正在尋求擺脫困境的辦法（過程客戶端 - 服務器代碼）。互聯網爆炸，突然帶有內置 Java 虛擬機（JVM）的 Netscape 出現在每個桌面上。為了被廣泛接受，Java 語言向 C++ 社區做出了幾個重大妥協：
像 C++ 壹樣，它是靜態類型，而不是像 Samlltalk 那樣的動態類型。
像 C++ 壹樣，它允許原語和對象。
它涵蓋了 C++ 的語法和控制結構。
為了獲得市場，Sun 保留了與 C++ 足夠接近的東西來吸引社區。Java 語言沒有必要比所有其他的面向對象語言都好。它只需比 C++ 好就行了。現在，其中的壹些妥協開始損害 Java 語言。
閉包
Java 語言允許比 C++ 更高的抽象，比如管理內存和字符串。但是，要達到像 Ruby 或 Smalltalk 語言那樣高的抽象，Java 語言還有很長的路要走。以叠代為例：用 Java 技術來完成壹個數組的叠代，要這樣寫： 用 Smalltalk 編程？
Avi Bryant 使用 Ruby 編程語言創建了壹個基於 continuation 的服務器，但是留下了 Smalltalk 的 Squeak 方言 —— 20 世紀 70 年代的初期，當 Ruby continuation 被證明是不太穩定（後來被修復）的時候，發明的壹種純面向對象的語言。然後他在 Smalltalk 的Squeak 方言上建立了 Seaside 框架並再未回頭。他現在使用 Seaside 為客戶快速地建立 Web 應用程序。他們願意采用諸如 Squeak 之類的語言是因為這個框架的生產效率非常高，大大降低了開發的總成本，並提前了產品進入市場的時間。 使用 Java? 編程語言進行 Web 程序開發與騎自行車這個例子有幾分相似。我們總是把原本簡單的事情復雜化。您需要確保壹切無狀態，才能獲得更好的可伸縮性。如果以 Servlet 或 JavaServer Page（JSP）的形式為用戶請求編寫多種獨立響應，就會留下許多散亂無章的獨立請求/響應塊。每個塊都需要確定其在整個應用程序上下文中的位置。您必須繞過前進路上的每壹塊小石塊，牢記各請求的狀態。如果顧慮得過多，在用戶單擊 Back 按鈕、打開第 2 個會話或者是嘗試直接轉到壹個較舊的 URL 時，您會發現自己“從把手上方翻了出去”。您希望可以假設用戶將按正確的順序執行任務，但這顯然是不可能的。絕大多數 Java 框架都不是以這樣的方式運作的。
本文將向您介紹壹種完全與眾不同的 Web 服務器：基於 continuation 的 Web 服務器。當然，Java 編程語言沒有為 continuation 提供內置支持（但其他編程語言有這樣的支持）。這裏，我將就基於 continuation 的服務器進行討論。在 “輕量級開發的成功秘訣：第 8 部分” 中介紹了壹種名為 Seaside 的此類框架，還介紹了壹些可通過各類創新方式提供有限的 continuation 支持的 Java 技術框架。