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