人們總是偏愛(ài)“大詞”。一個(gè)表達方式，如果聽(tīng)起來(lái)足夠響亮，寫(xiě)在紙上能夠吸引眼球，那就會(huì )變成很多人的新寵。但同樣是這些大詞，經(jīng)過(guò)太多人的傳遞、消費之后，原本的含義反而像硬幣上的圖案一樣被磨損殆盡：幾乎沒(méi)有人知道這些說(shuō)法到底是指什么了。在IT業(yè)界，“平臺（platform）”、“框架（framework）”、“構架（architecture）”等等就是這種人見(jiàn)人愛(ài)的大詞。幾乎每個(gè)廠(chǎng)商都愿意請來(lái)其中的一位、甚至多位為自己推銷(xiāo)。久而久之，這些說(shuō)法似乎適用于各個(gè)領(lǐng)域、各個(gè)層面：所有的軟件系統都是“平臺”，所有的開(kāi)發(fā)者都在自矜于獨有的“框架”。原本有確切意義的“好詞”，經(jīng)過(guò)這一番爭奪和濫用，也只能衰減為所謂的“buzzwords”，供市場(chǎng)營(yíng)銷(xiāo)人士們玩味了。
我想讓這些詞中的一個(gè)——“框架”——蕩污滌垢，重現青春。要完成這樣的任務(wù)，必須動(dòng)用重典才行。軟件業(yè)圣經(jīng)《設計模式》對框架有如下定義：“A framework is a set of cooperating classes that make up a reusable design for a specific class of software（一個(gè)框架，就是一組相互協(xié)作的類(lèi)，對于特定的一類(lèi)軟件，框架構成了一種可重用的設計）”。這個(gè)定義雖然主要著(zhù)眼于面向對象的軟件開(kāi)發(fā)，但已經(jīng)基本上給出了這個(gè)詞的核心含義：框架是軟件系統的設計、開(kāi)發(fā)過(guò)程中的一個(gè)概念，它強調對以完成的設計、代碼的重復使用，并且，一個(gè)框架主要適用于實(shí)現某一特定類(lèi)型的軟件系統。
為了更好地說(shuō)明框架是什么，也許還應該看看框架不是什么。
框架不是現成可用的應用系統。它仍是一個(gè)半成品，等待后來(lái)者做“二次開(kāi)發(fā)”，實(shí)現為具體的應用系統。
框架不是“平臺”。后者的概念更加浮泛和模糊——人們說(shuō)的一個(gè)平臺，可以是一種操作系統，一種應用服務(wù)器，一種數據庫軟件，一種通信中間件等等，因此“平臺”幾乎成了所有系統軟件的統稱(chēng)。在平臺的大家族中，框架的概念可能與近來(lái)人們常說(shuō)的“應用平臺”最為接近，但平臺主要指提供特定服務(wù)的系統軟件，而框架則更側重于設計、開(kāi)發(fā)過(guò)程，或者可以說(shuō)，框架通過(guò)調用平臺提供的服務(wù)而起作用。
框架不是工具包（toolkit）/類(lèi)庫（library） /API。目前流行的很多框架中，就包括了大量的類(lèi)庫和API，但是調用API并不就是在使用框架開(kāi)發(fā)。僅僅使用API時(shí)，開(kāi)發(fā)者完成系統的主體部分，并不時(shí)地調用類(lèi)庫實(shí)現特定任務(wù)。而框架構成了通用的、具有一般性的系統主體部分，“二次開(kāi)發(fā)者”只是像做填空題一樣，根據具體業(yè)務(wù)，完成特定應用系統中與眾不同特殊的部分。
框架不是構架（architecture）。構架確定了系統整體結構、層次劃分、不同部分之間的協(xié)作等設計考慮?？蚣鼙葮嫾芨唧w，更偏重于技術(shù)實(shí)現。確定框架后，構架也隨之確定，而對于同一種構架（比如web開(kāi)發(fā)中的MVC），可以通過(guò)多種框架（比如Apache Struts或Apache Velocity）實(shí)現。
那么，在企業(yè)應用系統開(kāi)發(fā)中，框架具有什么樣的意義？要闡明這一點(diǎn)，大概要看一看在這個(gè)領(lǐng)域里軟件開(kāi)發(fā)方式的演變。在計算機應用普及之前，只有少數大企業(yè)才負擔得起企業(yè)信息系統軟件，這一類(lèi)的軟件開(kāi)發(fā)也已委托定制（custom-made software）為主。在企業(yè)信息化基礎設施逐步完備之后，多數中、小企業(yè)也要在預算不高的前提下實(shí)施企業(yè)應用系統，按照以前的方式逐個(gè)定制開(kāi)發(fā)，是這種類(lèi)型的企業(yè)難以承受的。因此，對于一些需求簡(jiǎn)明的系統，往往會(huì )購買(mǎi)現成軟件（shrink-wrapped software）解決問(wèn)題。但是各個(gè)企業(yè)具體業(yè)務(wù)不同，需求很難統一，現成軟件只能滿(mǎn)足最通用的情況和最一致的操作（比如財會(huì )系統、網(wǎng)站內容發(fā)布系統等），對于頭緒眾多的業(yè)務(wù)處理就難以勝任了。
如何最大程度地萃取不同企業(yè)應用系統的共性，重復使用已經(jīng)完成的設計和代碼，對企業(yè)應用系統中典型場(chǎng)景給出最佳解決方案——這是一個(gè)“一般性”的問(wèn)題；如何讓一個(gè)早先完成的軟件產(chǎn)品貼切地適應極為多變、復雜的企業(yè)需求——這是一個(gè)“特殊性”的問(wèn)題。作為對這一組沖突的一種解決方案，不少廠(chǎng)商推出了自己的企業(yè)應用框架。這些框架往往是從大量的委托項目開(kāi)發(fā)中精選出的系統“不變項”，因此具有很強的普適性和實(shí)用性。
目前，主流企業(yè)應用框架中大都包含對以下問(wèn)題的現成解決方案：
* 持久性（persistence）：實(shí)現數據存儲、處理，數據與對象映射，數據緩存（caching）。
* 事務(wù)（transaction）：確保一組關(guān)聯(lián)操作正常、完整的執行。
* 安全性（security）：保證系統的通信安全、數據安全。
* 負載均衡（load balance）：在大量并發(fā)訪(fǎng)問(wèn)時(shí)，保持系統可用。
* 監控（system monitoring/management）：監控系統運行狀況，設置系統參數。
* 日志（logging）：記錄系統運行情況和異常，記錄特定用戶(hù)操作。
* 應用集成 （application integration）：與其他系統、應用程序集成。
* 認證/權限/組織角色管理（authentication/authorization）：管理系統用戶(hù)、組織職權結構，限制特定用戶(hù)對特定功能、特定數據的訪(fǎng)問(wèn)。
* 業(yè)務(wù)模型（domain model）：管理系統中業(yè)務(wù)對象的屬性、字段。
* 業(yè)務(wù)邏輯（business logic/rules）：實(shí)現業(yè)務(wù)規則和業(yè)務(wù)邏輯。
* 工作流（work flow）：實(shí)現多用戶(hù)、多環(huán)節之間的業(yè)務(wù)處理流程。
* 文件管理（file management）：管理文檔，實(shí)現系統內部的文件傳遞。
* 報表/打印 （reporting/printing）：實(shí)現數據打印，實(shí)現報表的定制和輸出。
* 門(mén)戶(hù)/信息發(fā)布 （portal solution）：發(fā)布企業(yè)相關(guān)的信息、新聞，提供企業(yè)客戶(hù)的訪(fǎng)問(wèn)入口。
* 通信（communication/messaging）：系統內部的消息、通知；系統與外部角色（比如企業(yè)客戶(hù)）之間通過(guò)不同通信媒介（電話(huà)、網(wǎng)站、郵件等）的互動(dòng)。
* 特定行業(yè)/領(lǐng)域模塊 （business modules）：實(shí)現特定行業(yè)、流域相關(guān)的業(yè)務(wù)模塊。
以上諸方面中，除了前四項目前主要由應用服務(wù)器解決之外，其他的部分本身都是專(zhuān)門(mén)的軟件開(kāi)發(fā)領(lǐng)域?？蚣艿淖饔?，在于確定上述每種因素的具體技術(shù)實(shí)現，并規定它們在系統中的組織方式和協(xié)作方式，從而給出完整的企業(yè)應用解決方案。
企業(yè)應用框架的特點(diǎn)首先是，當應用框架確定之后，系統的整個(gè)構架，也就是主體結構就已經(jīng)固定。因此框架的選取往往是方案選型的首要問(wèn)題。
其次，人們常常聽(tīng)信“組件式開(kāi)發(fā)”的一面之詞，認為系統搭建的過(guò)程類(lèi)似于搭積木，好像是用膠水代碼（glue code）拼合現成的組件或模塊。其實(shí)采用框架開(kāi)發(fā)時(shí)，系統的構建過(guò)程更類(lèi)似于填空——系統骨架早已完成，開(kāi)發(fā)者填寫(xiě)特定的代碼，由系統來(lái)調用?！对O計模式》中提到的“好萊塢原則（the Hollywood principle——Don‘t call us, we‘ll call you）”，非常符合我們談的這種情況。很多框架還允許下游廠(chǎng)商開(kāi)發(fā)系統插件（plug-ins），以滿(mǎn)足特定需要——這是另一種形式的“填空”。
另外，對于實(shí)現具體應用系統的二次開(kāi)發(fā)者來(lái)說(shuō)，不少任務(wù)都無(wú)需通過(guò)編程實(shí)現。比如要給一個(gè)業(yè)務(wù)模型增添一個(gè)新字段，或是要設置一種新的工作流程，這些工作都可以通過(guò)簡(jiǎn)單的圖形用戶(hù)界面（GUI）操作，或是修改部署描述符（DD），或是編寫(xiě)腳本來(lái)完成。也就是說(shuō)，相當多（而不是全部）的開(kāi)發(fā)任務(wù)是通過(guò)聲明/配置的（declarative），而不是編程的（programmatic）的方式實(shí)現的。系統往往會(huì )在啟動(dòng)或運行時(shí)載入相關(guān)的配置，據此實(shí)現特定的功能。
企業(yè)應用框架是菜場(chǎng)里的半成品。當我們面對要么自己下廚、要么去飯館吃飯的選擇時(shí)，我們往往會(huì )采取這種省時(shí)省力的折衷方案。但是選擇之所以為選擇，就因為其中肯定包含對收益和代價(jià)的權衡，都隱含著(zhù)復雜的利弊關(guān)系（pros and cons）。下面我們也來(lái)檢討一下企業(yè)應用框架的情況：
Pros：
* 縮短開(kāi)發(fā)周期
毫無(wú)疑問(wèn)，采用框架的開(kāi)發(fā)，要比一切從頭做起快速、高效得多。通過(guò)一般化（generalization）和重用（reuse）機制，框架能最大限度地加快一個(gè)特定應用系統的實(shí)現。
* 客戶(hù)化
如上所述，基于框架的系統有很多功能通過(guò)配置而不是編程實(shí)現，這樣也給用戶(hù)帶來(lái)了一定便利。比如，企業(yè)內部的IT人員經(jīng)過(guò)一定培訓，就能夠自己完成一種新的工作流程的設置。這對于不斷變化的業(yè)務(wù)需求是一個(gè)很理想的解決方案。
* 不重新發(fā)明輪子
框架對于大量典型場(chǎng)景給出了最優(yōu)的實(shí)踐。在具體開(kāi)發(fā)時(shí)，與其無(wú)視前人的成果，重新構思答案，不如套用這些成熟、穩定的做法。這不僅能加快開(kāi)發(fā)進(jìn)度，更能夠提升系統的質(zhì)量和健壯性。
* 可維護性/知識共享
完全通過(guò)委托開(kāi)發(fā)完成的系統很難由其他廠(chǎng)商維護?？蚣芡嵌鄠€(gè)企業(yè)、大量開(kāi)發(fā)者實(shí)踐的成果，因此能在一定程度上打破上述壁壘，增進(jìn)系統的可維護性。當框架使用者形成社區之后，還能實(shí)現更高層次上的知識共享。
Cons:
* 太多
半成品總有其代價(jià)。超市配好的一包菜里，老是又我們用不到的調料——但是我們卻不得不為之付費。同樣，為了達到一般性和普適性，框架總比緊湊、貼切的特定應用多出不少內容。二次開(kāi)發(fā)完成后，企業(yè)獲得的只是一種特定的實(shí)現，卻要為所有的客戶(hù)化可能性付費，為所有用不上的功能付費。這是一個(gè)相當讓人尷尬的事實(shí)。
* 太少
框架總是一種限制。就像半成品菜限制了我們的烹調方法，框架也限制了我們實(shí)際應用的可能性。當框架本身設計的足夠普適時(shí)，我們不太會(huì )感到類(lèi)似的限制。但是，情況往往正好相反——面對一個(gè)足夠特殊的需求，二次開(kāi)發(fā)者總有一種沖破框架的渴望。最后的解決辦法，往往是狡計、妥協(xié)和框架補丁的結合體。
* 效率
上面說(shuō)過(guò)，基于框架的系統中，具體功能經(jīng)常是通過(guò)配置實(shí)現的。與硬編碼（hard-coded）的方式相比較，這雖然能提供很大的靈活性，但也往往犧牲了運行時(shí)的效率。
* 鎖定
一個(gè)采用特定框架的系統幾乎肯定被鎖定在這個(gè)廠(chǎng)商的產(chǎn)品上。換言之，框架意味著(zhù)all or nothing式的態(tài)度，很難調和兩種不同的框架，各取所長(cháng)，更難把應用系統從一個(gè)框架遷移到另一個(gè)——這往往要求系統的全部改寫(xiě)。
* 學(xué)習曲線(xiàn)
一種框架也就是一種方言。要精通特定框架的開(kāi)發(fā)，你要熟悉其中的所有的用法、思路和弱點(diǎn)。對于開(kāi)發(fā)者，這也意味著(zhù)比較陡峭的學(xué)習曲線(xiàn)。
上面談到的種種弊端，還屬于一般開(kāi)發(fā)框架共有的缺陷。對于市面上流行的很多企業(yè)應用框架來(lái)說(shuō)，更大的問(wèn)題是框架產(chǎn)品自身的價(jià)格過(guò)高。我在別處也講過(guò)，企業(yè)應用系統項目往往不能靠運行安裝程序，再作簡(jiǎn)單的設置就完成，而是一個(gè)復雜、漫長(cháng)、不斷嘗試/修改的過(guò)程，或者說(shuō)，更近似于一種服務(wù)而不是簡(jiǎn)單的產(chǎn)品銷(xiāo)售。但是框架廠(chǎng)商的產(chǎn)品（或者說(shuō)是半成品）價(jià)格過(guò)高，經(jīng)常就蠶食了整個(gè)系統的大部分開(kāi)發(fā)預算，使方案總價(jià)偏重于框架本身而不是后期開(kāi)發(fā)。對于需求不甚符合原有框架，需要大量開(kāi)發(fā)的項目，或是需求本身不夠清晰的項目，這都幾乎肯定會(huì )導致整個(gè)項目的失敗。
軟件工程宗師F. Brooks曾經(jīng)表述過(guò)這樣一個(gè)道理：沒(méi)有銀彈（No Silver Bullet/NSB）。那意思是說(shuō)，沒(méi)有一種萬(wàn)應藥能夠戲劇性地提升軟件開(kāi)發(fā)的效率和質(zhì)量。最近的很多輿論好像是專(zhuān)門(mén)和這個(gè)經(jīng)典論述抬杠，動(dòng)不動(dòng)就把一些特殊的解決方案奉為銀彈。對于企業(yè)應用開(kāi)發(fā)而言，基于框架的開(kāi)發(fā)模式是多種選擇中的一種。在不少情況下，這種選擇是不錯的，但同時(shí)應該留意隨之而來(lái)的風(fēng)險，更不該以為，選定了框架就一定能保證項目成功。
很多企業(yè)應用項目的難點(diǎn)，在于客戶(hù)自身缺乏規范的企業(yè)管理制度和合格的計算機應用水平?？蛻?hù)不具備成型的業(yè)務(wù)流程，也無(wú)法明晰表達需求，不知道怎樣的應用形式對自身業(yè)務(wù)更合理：這種需求不清、或是需求劇烈變更的困境是困擾大量企業(yè)應用開(kāi)發(fā)項目的癥結。簡(jiǎn)言之，企業(yè)應用項目的成敗經(jīng)常是“業(yè)務(wù)”、“技術(shù)”、“管理”三種因素共同作用的結果，而單純引入框架，只能解決部分“技術(shù)問(wèn)題”。如果過(guò)于樂(lè )觀(guān)地估計框架在其中的作用，甚至認為它能解決任何項目的任何問(wèn)題，這對于本領(lǐng)域的各個(gè)環(huán)節（廠(chǎng)商、項目開(kāi)發(fā)商、企業(yè)客戶(hù)）都只能起到消極作用。
我個(gè)人的建議是：在搭建企業(yè)應用系統時(shí)，針對應用情況不同、預算/時(shí)限不同、對系統指標要求不同，有多種替代方案可以從中選擇。當需求明確、固定，又有現成產(chǎn)品完全滿(mǎn)足需要時(shí)，或者當企業(yè)想要以極低預算消除某個(gè)業(yè)務(wù)瓶頸時(shí)，應該優(yōu)先考慮現成產(chǎn)品；在需求明確、固定，但很難被現成產(chǎn)品完全覆蓋時(shí)，可以選擇應用框架，并由合格開(kāi)發(fā)商完成實(shí)施；在需求不夠明確，或者預感到需求會(huì )發(fā)生劇烈變更時(shí)，采用開(kāi)發(fā)源碼的應用框架，從而避免高昂的初期投資，并“軟化”框架帶來(lái)的種種限制，是另一種可供選擇的思路。還是那個(gè)比方，一頓飯怎么吃，究竟是下館子、買(mǎi)半成品或者全由自己動(dòng)手，還要視具體情形而定——我也希望，每個(gè)企業(yè)都能吃上可口順心的應用大餐。
聯(lián)系客服
