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