Posted on 2006-01-18 12:45
開源愛好者 閱讀(339)
評論(0) 編輯 收藏 所屬分類:
Spring
第 1 部分: 核心原則及原理
| 引用: |
在輕量級開發中，您基本上可以：
* 合并過程、技術和原理。
* 優先選擇較簡單的技術。
* 在一個穩固、輕量級的基礎上，進行構建。
* 盡量爭取最可能的透明性。
* 使用您可以利用的技術，如依賴注入和 AOP。 |
http://www-128.ibm.com/developerworks/cn/opensource/os-lightweight1/
第 2 部分: 如何減輕容器
| 引用: |
現在，您已經大概了解了輕量級容器。您了解了以下的基本設計理論：
* 構建一個接受 POJO 的容器，而不是受限制的組件
* 使用依賴注入來松散、解析依賴性
* 使用攔截和 AOP，將服務與 POJO 相關聯 |
http://www-128.ibm.com/developerworks/cn/opensource/os-lightweight2/
第 3 部分: Spring 露出水面
| 引用: |
Spring 的重大意義
對于那些使用 Spring 的人，Spring 無疑是革命性的。它的一些簡單思想引發了影響深遠的結果：
* Spring 有力地開拓了企業級服務容器。使您不再“隸屬”于容器提供的 API 或服務。可以使用 Spring 上下文管理預打包的服務，整合第三方服務或自己編寫服務。
* Spring 在可測試性方面有了長足的進步。通過 Spring，能夠使用依賴注入將模擬對象插入到難以接觸的位置，在容器外運行對象（因為這些對象是 POJO），甚至使用容器提供不可預知的數據。
* Spring 的膠水代碼使得只要編寫很少的代碼就可以輕松插入企業服務。編寫的代碼越少，維護和擴展代碼時工作量就越少。
* Spring 代表一個開放源碼項目，重新定義了 Java 商業小組開發軟件的方式。Spring 對于最新 EJB 規范的影響是不容置疑的，同時也是非常重要的。 |
http://www-128.ibm.com/developerworks/cn/opensource/os-lightweight3/
第 4 部分: 輕量級容器的比較
| 引用: |
哪一個最好？
目前，只有一個真正的答案。HiveMind 具有有趣的創新，PicoContainer 具有易于使用的模型（理論上），但社區似乎已經投票選擇了 Spring Framework。隨著時間的推移，新的容器可能會成長，HiveMind 可能不斷獲得市場份額，但目前，Spring 是您的最佳選擇。
如果您愿意冒一些險，而使用不太成熟或不太流行的容器，您可能決定實現 HiveMind（如果需要模塊級別的配置）或 PicoContainer（如果想要微小的容器）。如果需要許多膠水代碼來集成持久引擎、事務處理策略和安全性等方面，Spring 具有最完整的組件堆。但請記住：您可以在 HiveMind 容器中使用 Spring 組件。 |
http://www-128.ibm.com/developerworks/cn/opensource/os-lightweight4/
第 5 部分: 在保守公司進行敏捷開發
| 引用: |
本文介紹合力完成一種不同的活動：應用程序開發。敏捷開發流程，比如極限編程（Extreme Programming，XP）和 Scrum，尋求降低流程開銷。盡管存在許多不同的流程，但它們當中都有一些共同的趨勢：
* 越來越重視客戶參與，而非重量級需求文檔
* 通過重構改進質量和設計；重的、自動化的單位測試；連續集成
* 小團隊，較少的正式溝通和更多的非正式溝通（15 分鐘的站立早會，更多的配對編程）
* 短而一致的周期，最后是客戶反饋
敏捷方法剔除了不需要的流程，直到只留下完成工作所必需的流程。盡管許多編程人員理解輕量級、敏捷方法的強大功能，但許多管理人員習慣使用更傳統的流程。如果您認為敏捷可以幫助您，那么通過應用下列思想來學習如何協調傳統管理與敏捷開發流程：
* 將您使用的語言改為側重于原則，而非流程。
* 創建小而靈巧的團隊。
* 重視可測量的交付。
* 重視簡約性。
* 重構代碼并自動化測試。
* 獲得客戶反饋。 |
http://www-128.ibm.com/developerworks/cn/opensource/os-lightweight5/
第 6 部分: 持久性策略
| 引用: |
神話 1：技術總是最要緊的。
不論您是在談論 RDBMS 還是持久性框架，持久關系都是長期的。您需要知道您選擇的方案將長時間擁有市場份額。如果不是，您將冒著被迫離開指定框架的風險，而這并非您的意愿。
神話 2：對象關系映射程序（Object Relational Mappers，ORM）隱藏了所有的數據庫問題。
持久性框架簡化了一些問題，但引入了一些其他的問題。如果您不理解底層架構，那么找懂的人問，或者不要使用對象關系框架。
神話 3：JDBC 總是比 ORM 要快。
當然了，一個非常協調的特定 Java 實現總是會打敗普通的 ORM，但是您很難找到一個非常協調的 JDBC 應用程序。JDO 和 Hibernate 之類的框架提供許多方法來提升性能。
神話 4：ORM 總是合適的工具。
常常，您會發現要求更好的訪問 SQL 的問題。您也會發現面向批處理的而非交互式的問題，或要求直接訪問數據庫行，而非完整的對象模型。這些問題并沒有充分利用 ORM。更糟糕的是，一些解決方案也許會礙事。
神話 5：Java 的 ORM 解決方案是處理持久性的惟一的好方法。
其他語言同樣有具有競爭力的持久性策略。Microsoft? 策略傾向于接受關系數據庫并與行集一起工作。您讓應用程序與關系模式緊密結合，但是您獲得了一種能力，可以綁定行集到用戶界面控制，并整個應用程序中將它們與緩存策略集成，甚至脫離防火墻與緩存代理。Ruby 語言有 Rails，后者有一個有效的記錄框架。對于許多類型的問題，記錄框架比 Java 技術解決方案更加動態和高效。
|
http://www-128.ibm.com/developerworks/cn/opensource/os-lightweight6/
第 7 部分: Java 替代方案
| 引用: |
簡而言之，Java 語言不是一種生產效率非常高的程序語言。創建者做了一些聰明的妥協來從 C++ 奪取控制權，但我們開始為那些妥協付出代價了。在 Beyond Java 一書中，我詳細討論了這些問題。我仍然為大多數的項目使用 Java 語言。很容易找到適合我需要的框架。我能很快地找到程序員和工具。它是一種經過驗證的編程語言。我的許多客戶有太多的遺留代碼，修改起來工作量太大。
但是，我已經開始為某些已付項目使用不同的語言。對于大型關系數據庫上的基于 Web 的用戶界面，Ruby on Rails 是有效的。對于要求有限的可伸縮性和可用性但要求復雜導航的應用程序，Seaside 是有效的。許多語言處理豐富的客戶端開發要比 Java 語言好。
我還發現，如果贏利較大，處于創業階段的公司愿意承擔更多的風險。如果生產效率是首要關心的問題，團隊很小，并且您正在解決一個很適合于動態語言的問題，那么使用動態語言是很有意義的。通過遷移到一種更加動態的語言和一個更加適合項目的框架，我為一個客戶節省了 60％的項目預算。通過遷移到一種技能要求沒有 Java 語言那么嚴格的語言，我讓另一個客戶減少了 30％ 多的職員。
底線？有時，當考慮輕量級開發時，值得脫離 Java 語言看一看。在接下來的幾篇文章中，我將離開 Java 語言來探索一種新的語言和幾個輕量級框架。 |
http://www-128.ibm.com/developerworks/cn/opensource/os-lightweight7/
Part 8: Seaside
| 引用: |
In mid-1999, Tennessee rivers were low, but the Ocoee River was flowing well. As I approached a rapid called Hell Hole, I could see the other tourists shudder with fear, but I wasn't worried. In this massive raft, we had nothing to worry about. In fact, up ahead, a kayaker was playing in the hole, and his body slowly slid down, as if he were on an elevator. We passed over, and he came right back up, still surfing the hole. Strange and wonderful.
My raft might be bigger and safer, but there were things it just couldn't do. In his tiny kayak (called a playboat) he could surf the waters beneath the surface to do things seeming alien to those of us in the raft. The Seaside framework is like that. You wouldn't use it for all Web development, but under these circumstances, you might give it a try:
* You have sophisticated work flow and want to manage flow from one simple program.
* You don't want to stay with a safe, conservative language, like the Java? programming language.
* You like Smalltalk or one of the Smalltalk dialects.
* You have a start-up company in which picking a productive technology is much more important than picking a fast one.
This article gives a high-level tour of Seaside. If you like what you see, you'll have enough information to dive deeper. |
http://www-128.ibm.com/developerworks/opensource/library/os-lightweight8/