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