以前學習 Ofbiz 的時候看到過老戴（Ofbiz 的總設計師 David E. Jones，我們都這樣叫他）發的一篇帖子說明 Ofbiz 爲什麼不能直接使用 Struts。今天找了找，應該就是這篇了：
http://www.geocrawler.com/archives/3/12465/2002/3/100/8002721/
如果想要學習框架的設計，Ofbiz 是一個非常好的起點，它是真正面向企業應用（面向業務的，而不是純技術的框架，純技術的框架是沒有多大價值的）而設計的，而 Struts、Turbine 等框架對於簡單的 Web 應用還可以，但是對於複雜的企業應用就顯得太單薄了。企業應用的問題並不是靠簡單地分出 MVC 就可以解決的。
Ofbiz 中文網站：
http://www.ofbizchina.com
老戴基本上沒有對 Struts 發表太多的見解。我來解釋一下他的這段話，主要原因是 Struts 的設計與 Ofbiz 的設計有較大差別，因此很難無縫地集成進來。而老戴以爲以自己的能力，寫一個 MVC 框架是件很容易的事。所以在 Ofbiz 中，MVC 框架、OR Mapping 全部是自己設計的。老戴的一個基本思想是通過 XML 對系統進行建模，以 XML 來定義系統中不同的層次關係，儘量減少寫 Java 代碼的數量（甚至創造了一套以 XML 爲基礎的 Mini Language 來做一些簡單的邏輯處理）。而在 Struts 中仍然需要寫大量的 Java 代碼。Struts 在減輕開發人員工作量方面做了一些努力，但是做得還不夠（甚至帶來了額外的複雜性，我認爲 Ofbiz 的表示層比 Struts 更容易理解）。如果說面向對象開放框架的目標就是實現更大程度的代碼重用的話，無疑 Ofbiz 在這方面要比 Struts 更成功。
根據我的使用經驗，Ofbiz 中的 Event Handler、Service、和 Entity Engine 的設計是非常靈活的。確實極大地減少了 Java 代碼開發量，換之以更多的 XML 配置文件，但是這個工作量要比做 Java 開發小得多。
某種程度上，Ofbiz 和我們現在設計的這個框架有很大的相似之處，我們都是面向業務問題的框架而非學術性的純技術框架。
這裏是不是牽涉到一個如何對待技術框架和業務框架的問題？
按我的理解，框架技術實際上就是流程固化技術。在框架技術中應用的很多的一種就是回叫機制（callback），對比MFC之類的東西，框架其實就是由設計好的工作流程調用具體的數據結構和算法（在C/C++中使用函數指針，Java中使用接口）。
J2EE我更多的是做爲一個框架來理解，而不僅僅是一組API。J2EE面對的問題域主要集中在分佈式計算，那麼它就固定了一套處理分佈式計算的流程。我把它看作一個技術框架，它處理的流程是面向機器的：如何定位資源；如何管理連接；如何傳遞消息；如何處理事務；如何處理安全等等，這是所有業務的基礎。所有的商用邏輯最終都是要轉換成這些計算邏輯。
從這個角度看，實際上J2EE的抽象級別還是相當低級的。程序員的作用就是把商業邏輯轉換分解爲計算邏輯。隨着程序的變大，人們自然的想在技術框架上再做一次抽象，把商業邏輯向技術邏輯轉換的流程固定下來，這樣就可以大大減輕開發的負擔。
這樣就要求設計者對商業邏輯和技術框架都相當瞭解，才能完成這個抽象。--誰說軟件開發變簡單了？
在這個趨勢下，程序員的兩極分化必定越來越大，一方面向框架的設計者集中，一方面向框架的使用者集中。各種各樣的框架也會越來越多。
優秀的開發者會根據合適技術建立適合自己業務的框架，而不是盲目地追逐現有的熱門的框架。
stuts主要是面向Web開發的，而真正的企業應用的UI層是很薄的（dlee，這是你說的哦：） ），或許，是這個原因ofbiz沒用stuts。
無明兄，我很同意你的觀點。你對框架作用的描述比我要清楚的多。J2EE 確實只是對低層次的邏輯進行了抽象和建模，做的還遠遠不夠。這也是我對 EJB 由熱衷到冷靜到失望的原因。我接觸過很多朋友對 EJB 還有 MVC 都不是非常的熱衷。但是對於初學者，往往最喜歡談論的就是 CMP 和 MVC。我寫了很多反對的意見，並不是說它們沒有價值，而是它們完全沒有達到 Marketing Hype 所描繪的理想境界。在我看來，企業花費巨資購買一個僅僅實現了 J2EE 規範的 WebLogic 是完全沒有價值的，因爲沒有解決任何的業務問題。當然有人會反駁說一分錢一分貨，我只是覺得 Java 技術發展到了今天，完全有性價比更高的選擇。J2EE 把對業務進行建模的任務完全甩給開發者，這是一個很大的問題。因爲開發者完全不清楚需要把哪些業務對象表示爲 Servlet，哪些表示爲 Session Bean，哪些表示爲 Entity Bean，即使發明了那麼多的 Patterns，如何對業務建模仍然有很大的難度。業務建模的複雜程度要遠遠超過對連接池這樣的簡單對象的建模。隨着軟件技術的成熟，軟件開發者關注的領域越來越向問題域轉移，這也是爲什麼最近 AOP 興起的原因。AOP 是直接關注問題域的新型開發方法（當然 AOP 是不能夠脫離開 OOP 的，它是 OOP 的最新發展）。
在我們看來，今後幾年國內的企業對於面向業務的開發框架的需求將呈現一個快速的發展階段。我們希望自己在這個市場佔有一席之地。我們希望自己將來成爲框架的設計者而不是一個純粹的使用者。這樣的業務框架設計的難度比設計一個純技術的框架要高的多，因爲你必須有多年大型項目成功實施的經驗，對某一行業的業務非常熟悉之後才能夠設計好。設計一個框架不難，設計一個真正有用的框架就很難了。IBM 也沒有什麼象樣的框架，所以只能拿開源的東西直接來用（WebSphere 中有多少東西都是來自於開源軟件）。IBM 是在幫助開源社區，但是他拿走的也不少。
我覺得你對 ejb 的理解有些偏差，ejb 的核心是什麼？我想應該是tp monitor，而不是什麼 cmp & bmp 。
只有瞭解什麼是 tp monitor ，才能確切知道 EJB 的價值。自從60年代tp monitor 軟件（cics）出現後，在商業領域一直沒有能夠出現 cics 的競爭者。而tp monitor 軟件的市值之大另各軟件公司所垂涎（500強企業中95%以上使用cics）。而傳統的 TP monitor 軟件是面向過程的，所以在面向對象的語言出現後，如何實現面嚮對象語言的事務控制一直爲工業界所關注，EJB 的出現可以說另業界興奮不已，這就意味着企業的核心軟件終於可以用先進的面向對象的語言來編寫了。但是很遺憾，ejb 還是不太成熟，所以直到現在，（大）企業的核心軟件仍然由cics所盤踞（部分原因是大機的緣故）
爲什麼tp monitor這麼受重視呢？
非常簡單: 是因爲企業的軟件過於複雜，交易量太大而且事務交易過程決不允許出錯！真正能夠達到工業強度的 tp monitor 軟件，你的選擇基本上很少，而能夠用在大型機上的 tp monitor ，基本上你沒有選擇，而價格更是讓你咋舌！而業界對這個東東也是恨之入骨(有如微軟)。
你說的有些道理。但是大量的應用不一定要用到 EJB 的跨數據庫兩階段提交，它們可能只需要用到 JTA 所提供的功能就可以了。在涉及到跨數據庫兩階段提交的場合（比如銀行的轉帳業務），我確實還不清楚有比 EJB 更好的選擇。CORBA 比 EJB、WebService 都要成熟，然而它缺少的正是一個 TP Monitor，而 EJB 以規範的形式實現了這樣的一個 TP Monitor，確實減輕了很多的開發工作量。而且我相信業界主流的 Java 應用服務器在高可用性方面完全可以滿足重負荷業務的需求。在分佈式應用，尤其是涉及到大範圍的事務處理的場合，我相信 EJB 是目前最好的選擇。然而對於一般的信息管理系統，EJB 確實有些過於重量級了。
EJB 屬於框架的範疇，任何一種框架都有其適用和不適用的場合，拋開具體的應用領域來談其優劣都是不適當的。我還看到過有人認爲“工作流必須要用 EJB 來實現，否則是無法想象的”這種說法。“有了一個錘子，看到什麼都是釘子”這是我看到這種說法後直接想到的第一句話。
我想我們說的都有一些道理，但是應該加一些限定，否則就變成無邊際爭論了。在我們的開發領域，確實看不到很多必須要使用 EJB 的理由。我也並不認爲做分佈式應用就一定比設計 MIS 系統要高級，大家各有各的難處。
這類銀行的核心應用正是我說的少量應用。你不能讓所有的人都跑去做銀行應用吧？就銀行這樣的關鍵應用而言，不用 EJB 確實很難達到高可用性的要求。我們做工作重要的是要站在巨人的肩上，EJB 是一個巨人，但是它也不是不發展了。光是說“EJB 就是好來就是好”（有點象腦白金的廣告）而看不到它的侷限性是要犯錯誤的（別介意，我沒有特指）。EJB 確實做了很好的工作，但是如何更方便地對數據做複雜的加工處理卻是 EJB 沒有解決好的問題（這正是我說的 J2EE 甩給開發者來解決的問題），要由 Hibernate 等面向數據建模的框架來解決。實際上 Hibernate 解決的也是局部的問題，研究 Hibernate 應該放到企業數據流的大背景下思考才能把 Hibernate 的優勢充分發揮出來。開發者現在需要的不僅僅是 EJB 這樣解決了關鍵技術問題（比如 TP Monitor）的框架，他們還希望得到一個能夠幫助他們解決業務問題的業務框架。不知道你有沒有真正理解我說的話，解決技術問題是不值錢的（尤其是在 JBoss、JOnAS 等 Open Source 的應用服務器出現後。Java 應用服務器市場已經是一個過度競爭的飽和市場），解決業務問題纔是值錢的。位於產業鏈的高端的企業纔是最舒服的，這也是我們將來的發展方向，我們會在將來適當的場合採用 EJB，關鍵是看是否有這方面的業務需求（分佈式的應用，對事務處理的高可用性要求很高）。
JDBC 過於低層了，如果永遠只在如此低的層次上工作，那麼複雜的大型項目的完工就遙遙無期了。好在 OOP 給我們提供了無限的封裝能力。JDBC 之上有 Hibernate、JDO，還有 Ofbiz 中 Entity Engine 實現的 OR Mapping 框架。這些開發框架極大地減少了開發的工作量。這些框架的目標就是要在大部分場合完全替代 JDBC。然而我覺得有些遺憾的地方是 Hibernate、JDO 的抽象層次仍然沒有上升到業務對象的高度（所以它們不能夠作爲單獨的解決方案，而只能作爲更大的業務框架中的嵌入式組件）。業務分析和軟件設計在國外是分的比較開的兩個領域，分析領域有很多模式（分析模式），最後得到是分析對象，這些分析對象是直接與業務相關的，也是商務人員比較容易理解的。設計領域也有很多模式（設計模式），最後得到是設計對象（差不多就是計算機中真正的對象）。但是目前從分析對象到設計對象的映射還有較大的空隙（gap）需要填補，填補了這個空隙，軟件從需求收集、業務分析到設計、開發、部署、測試的全生命週期就能夠以一種無縫的方式結合起來。Borland 整合了 Together 和 JBuilder 後可能會有一個比較好的方法。我還沒有試用過 Together for JBuilder，你可以看看其介紹。
解決業務問題的業務框架有很多，IBM 兜售的解決方案中就有面向業務的框架，比如以前的 E-Commerce Suite（現在好象叫 WebSphere Commerce Suite 了）。開源的業務框架我只用過 Ofbiz，感覺比較好，你可以找些資料看看。
我並沒有貶低技術框架的意思。我這樣說是由小企業的發展策略所決定的。小企業做通用軟件生存下來的可能性很小，只能先依託一兩個行業，深入研究該行業的業務，通過成功實施項目壯大自己。如果同時做多個行業，很難都做好，極有可能任何一個都做不深，那樣是沒有任何競爭力的。
對於企業來說，通用的解決方案往往不能很好地解決他們的業務問題，因此他們需要爲企業（或者是這個行業，如果企業的業務有代表性的話）量身定製的解決方案。軟件業本身就是一個服務行業，軟件業的利潤將會越來越多的向服務轉移（而不是靠賣發行包）。企業對爲自己量身定製的解決方案（高級服務）的需求也會越來越大。我聽說過有些做通用解決方案的公司（甚至是有些大公司），不管對於哪個行業，推銷的都是一樣的方案。他們的售前見了客戶除了吹噓自己的技術實力和成功經驗外，對於客戶的業務談的很少，顯然是沒有做過認真細緻的分析（完全是一派以我爲主，強行推銷的派頭）。客戶需要這樣的解決方案嗎？可能你前腳走人他後腳就把你忘掉了（想賺我的錢，你還嫩點）。在這個領域如果我們把工作真正做好了，以小搏大是完全有可能的。
我來舉個例子。低級妓女爲很多人服務，她的收入很少。高級妓女被某個億萬富翁包下了，爲這個億萬富翁提供全方位的周到服務，她的收入肯定比低級妓女要高（大家可能都看過“風月俏佳人”這部電影）。這個比喻雖然不雅，但是確實說明了對高級服務的需求是很大的。
IT 業的產業鏈最近幾年變化很大，但是最穩定的就是那些高端的廠商，因爲他們提供的服務是很難被替代的。市場對技術框架的需求將趨於飽和（這也是爲什麼那麼多很好的技術框架不得不開源的原因，要麼是根本賺不到錢，要麼是根本沒有想過用這個框架來賺錢，這個框架只是更大的業務框架的一部分），而市場對業務框架的需求將越來越大，這個機遇是我們無論如何也要把握的。解決業務問題的能力是最難複製的，也是我們應該孜孜不倦追求的目標。你可以看幾本講 J2EE 的書來學習基本的技術，但是如何對業務進行建模，什麼樣的架構纔是真正實用的架構你仍然是一個門外漢。
進入 IT 業就走上了一條充滿風險的不歸路，成爲業務專家不是你本人是否喜歡的問題，而你要生存下來就必須要走的路。所以我總是對別人說一定要靠兩條腿走路，技術和業務，缺一不可，而且都要做好。
ofbiz 只能算是 opensource 界的高級專案
集合了許多 opensource 產出了一個完整的架構
如果和 bea weblogic platform 比起來還是不行
所以拿著 ofbiz 來否定 struts 是不公平的
因為 bea portal framework 就是基於 struts 開發上去的
我反而不會看好 Ofbiz 的未來
即使他的未來有更多的整合方案 更多的元件增加進來
只是讓他更加肥大 肥大到讓初學者畏怯
因為到現在, 我尚未有看到更方便的 ide 工具有支援他
反而來看 struts 的支援度, 如果單純的直接開發
或許會蠻麻煩的, 一大堆麻煩的設定
但是這些設定的存在都是有他的道理的
因為那不是給人讀的 ( 雖然我都直接寫 )
卻是給予 ide 方便的存取修改新增的方式
可以讓初學者輕易地開發著程式
Turbine 或其他 framework 如 WebWork ...
和 Struts 的優劣勝敗我不予評論,
基本上, 市場機能將決定一個 opensource 的興衰
即使我認為 turbine 的優點較多 支援更強
但是對於一個初學者來看...
我反而推薦 struts 當作基礎的入門
因為我喜歡單純的 framework 作為 mvc framework
我可以自由地增加我所需要的東西
OR Mapping 我可以選擇 Hibernate , OJB , EJB 甚至 ibitis 等等
Security 我可以選擇 securityFilter, pow2acl 等等
...........
即使 ofbiz 幫我做了很多
我卻不認為我可以直接讓客戶使用
只會造成我要閱讀他們的原始碼作修改......
採用 struts 有另外一個好處是
當大家都使用的時候, 你可以找到更多適合的資源附加在你的系統
如果採用過 bea workshop 8.1 開發過 web
就知道再複雜的程式也可以靠著拖拉與設定完成
此外 j2ee 的 support 都是過之而無不及的
一個企業除了安全性穩定性之外
要的就是能夠在最短的時間產出最好的產品提供給客戶
拿著 ofbiz 和 weblogic 比
似乎太對不起 ofbiz 了
根本就是讓大象去踩死一隻小螞蟻 :P
不過我不否認 ofbiz 的價值,
用在一般小企業倒是不錯的一種解決方案..
還有他提供的是一種思路給予大家
如何套用各種 opensource 讓一個企業具有更完整的解決方案
jini，你說的是有一些道理的。你要做的這些事（組合各種開源的 Framework）正是 Ofbiz 已經做過的事（我們現在也在做這件事，爲建造一個企業級的業務框架而奮鬥。但是我們更多地是立足於自主開發，而不是直接採用開源的方案。因爲我們要涉足的領域目前還沒有很好的開源項目）。很多人可能覺得 Ofbiz 中某一方面的設計不是最好的（比如 MVC、ORM）。但是它們的設計都是爲整體的目標服務的。不一定各方面的超強工具（Struts、Hibernate、Castor、Tyrex......）簡單組合在一起就是一個穩定的企業級業務框架。
以前我在 linuxtea 發的帖子中說：
Larry Ellison 在中央臺的對話中說，你可以買下零件自己組裝汽車，但是 Oracle 是組裝整車的公司，某一部分不一定是最好的，但是它們組合在一起是最有效率的，每一部分都可以很好地發揮作用。
現在的 Open Source 世界所提供的就是這樣的一些汽車零件。把這些零件拼裝起來就可以生產整車了，但是你不能簡單地拼湊起來，那樣是跑不過別人的車的，從 DIY 到提供真正的商業價值的道路還是很遠的。
對於目前國內的很多企業來講，他們急需儘快地從解決基本的技術問題跨越到解決複雜的業務問題（先要賺到足夠的錢活下來），Ofbiz 對於他們加快項目的開發進度有非常大的幫助。
我本人也並不是很喜歡別人一股腦地向我推銷什麼 All-In-One 的解決方案，更喜歡解決某一方面問題的小而精的方案。我們並沒有採用 Ofbiz，但是可以借鑑 Ofbiz 中好的設計思想（適當的借鑑是絕對必要的，否則就是閉門造車了）。既然已經有了 Ofbiz 這個東西，它就樹立了一個標杆，這是你無法忽略的。就象前幾天我和幾個同學激烈爭論的數據庫選取問題，Oracle 已經樹立了一個標杆，這個標杆無論你如何厭惡，都是無法繞過的。MySQL 的愛好者可以閉上眼睛當作這個世界上根本就沒有 Oracle，但是我可並不想這樣做。
我們這裏討論還是要採取兼收幷蓄的原則，歡迎大家對於各種 Java 開發框架（開源的或者不開源的）展開客觀深入的討論。這些討論對於來這裏的每個人都會是有益的。
| 孤魂一笑 寫道: |
| 其實說的難聽一點：利益最根本。選擇什麼看短期長期的利益。 |
呵呵，怎麼能說難聽呢？這纔是技術人員最終要考慮的問題。你總想有一天實現自己的價值吧？解決了客戶的業務問題，首先給客戶創造了商業價值，然後纔有可能實現你自己的價值。軟件業將越來越向服務業的方向發展，將來的競爭將是高層次的殘酷競爭。最終的受益者將是客戶（企業和最終用戶），並且會帶動整個社會向信息化的轉型，改善全社會的資源配置，提升全社會的生產效率。
業務問題往往是複雜的，從要解決的業務問題入手展開思考，纔有可能把技術用好用深入。
我來舉個例子：假設我們要做一套報表服務器。客戶有很多下屬單位，下屬單位的報表都要彙總到總部，在總部以各種方式進行彙總。如何解決這個分佈式系統中數據的一致性？首先要保證可靠的傳輸，如果各下屬單位以撥號方式與總部相連，而不是永久連接，如何保證傳輸可靠性？這些報表數據如何定義，如何彙總？生成的這些報表需要進行審覈，要用工作流方式來實現。要對報表進行完善的管理，如：設置報表的各種參數，設置報表是自動生成還是手動生成，對報表進行檢索、修改、刪除，還要對報表的訪問權限加以控制。合在一起就是一個很複雜的問題。目前任何的技術框架都沒有給你提供現成的解決方案（因爲這完全是一個業務問題）。
由業務問題入手，可以應用到的技術範圍是無限寬廣的。具體採用什麼框架，是一個 tradeoff 的藝術。
其實這個討論是相當泛泛的。爲什麼 Ofbiz 中的 MVC 比 Struts 靈活，它們究竟是怎樣設計的等等問題都沒有講清楚。這些問題需要留待以後深入討論。大家先有一個學習的方向，然後在具體工作中再去體會。框架具有一定的複雜性，而一個人的時間是有限的，抓緊時間，瞭解更多的框架，最終找到最適合自己的纔是重要的。我不太贊成所有項目都用相同的框架來開發，因爲不同的框架對於項目的進度和質量有很大影響（再次強調選擇正確工具的重要性，比如我用 Eclipse 做 Java 開發的效率是採用 Vi+Javac 的十倍）。即使從成本上考慮，也不應該所有項目採用相同的框架。我是很相信我們的程序員的學習能力的，他們在 3、4 個月的項目開發期間學會使用一種新的框架是綽綽有餘的（掌握了一種框架再掌握其它框架就會比較容易，而且還會加深他們對原先框架的理解）。當然首先我要確定這種框架確實是最適合的（我認爲最適合，還是帶有一定的主觀性）。一種框架就是一種解決問題的思路，從公司的角度，開發人員掌握多種框架也符合公司的利益（應該鼓勵開發人員學習和實現自己的想法，而不是把他們當作編程機器嚴加看管）。
根據我對 IT 行業多年來的觀察，成功者往往都是那些真正專注於解決問題的人，我更多的指的是業務問題。
最後再說一句，對各種框架進行深入討論是有必要的，不要搞神祕主義。任何問題只要找到其癥結，都是可以討論清楚的.
關於框架，我還想說的是現在有很多開源的框架，都只解決了企業級應用中的一部分問題。這些不同的框架設計理念不同，彼此存在着一些內在差異，把這些框架簡單組合在一起是否就能大幅度提高開發效率我是很懷疑的。一個成熟的框架必須要保證整體的概念完整性，而概念完整性纔是軟件質量和開發效率的關鍵。
老戴爲什麼沒有采用 Struts 而要自己設計，就是因爲 Struts 的設計理念與 Ofbiz 有很大的差距。而 Ofbiz 中的各個部分確實保持了整體的概念完整性，這與其只有幾個主要的核心設計人員是分不開的。
不同的開源框架隨着使用人數的增加，在更高的版本中會加入更多的功能，隨着功能的膨脹，最後甚至想無所不包，企圖解決一切的問題，這樣它們彼此之間將產生很多功能上的重疊，把它們簡單組合在一起更容易出問題。
框架的重用是高粒度的重用，只要能充分保證概念完整性，無所謂這個框架是採用對象建模、數據建模還是混合方式設計出來的。無論對象建模還是數據建模都是着眼於技術層面的重用，業務解決方案的重用對我們纔是最有意義的重用。potian 的話並沒有說服我框架一定要完全採用對象建模的方式來建造（因爲我知道很多問題完全採用 OO 是無法解決的），只是讓我理解了對象建模的優點。
我的一位朋友前幾天說的話我覺得很有道理。
| 引用: |
| 每個框架都是有自己的優點和缺點，適於解決特定領域的特定問題。開發框架是學術界討論的，而不是工業界討論的。工業界的目標是作出一個能夠解決問題的工具，然後用它解決現有的問題，隨着問題領域的擴大，對工具進行逐步修改，直到有一點這個工具不適用，推倒重來。 |
現在爲什麼會有 JSF？是不是因爲 Struts 已經不適用了？