web開發平台之研究

前言

在去年我寫web報表開發技術專題系列文章之時，就想寫一寫對web開發平台之探索。沒想到一拖就是又近一年的時間過去了。前幾天看到csdn首頁的 如何輕松建構自己的業務應用程式 的連結，便點進去看了看，原來是電子書《建立随需應變的應用程式：Force.com 平台簡介》（注冊下載下傳還可以抽獎，有興趣可以試試，呵呵！）。花半天時間看了看，感觸頗多，忍不住便寫下了此文。

web開發平台之定義

       從程式設計之初，便免不了和函數，類，抽象，接口之類的東西打交道。久而久之，自然會對此進行總結，這便是開發平台之由來。在中國的程式員之中，有很大一部分都是編一些企業資訊化，政府資訊化之類的程式。其特征是資料放在資料庫中（如sql server庫，oracle庫等等），做一些增删改查之類的表單，出一些統計圖表，用于對業務資訊進行管理而已。随着internet的流行，自然又要求把這些都放到internet上，即web化。因為這些有一定的共性，做得多了，便會想将共性提取出來供大家共享。這便是web開發平台之初衷。

       在網上，有很多差異很大的東西都稱作web開發平台，為正視聽，對于web開發平台，我的定義是指：

1指b/s結構的程式，即web化。

2 用于實作企業資訊化，政府資訊化之類的資訊管理系統的開發。

3 用于快速開發對資料庫進行增删改查之類的表單及統計圖表

web開發平台之前身

       在internet出現之前，人們就對如何實作快速開發做了很多研究。象用友金蝶都有自己的開發構件庫，象SAP的ABAP開發平台等等。象SAP的ABAP開發平台太複雜，一下子很難用起來；而用友金蝶的開發平台又隻能自己用，無法開放出來，即難于通用。也就是說，對于開發平台的早期研究表明：要麼功能強大，使用複雜；要麼難于通用。

       人們還來不及對這些問題進行改進時，internet的大潮來了。這些早期的開發平台也被迫要轉向web開發平台了。這些問題顯然不會被internet的大潮自動沖盡。忽視早期開發平台的這些問題，沒有很好地解決通用性和個性化的沖突，正是當年ASP（應用服務提供商）失敗的重要原因之一。

       對于web開發平台之前身的開發平台的研究，可以積累web開發平台的經驗，避免走更多的彎路。利用web的便利性，也許能獨辟蹊徑，一舉使web開發平台實用起來。

web開發平台之亂象

       下面摘錄網上的一些web開發平台的介紹：

用xxx開發應用軟體，會具有前所未有的高效率、高品質、高适應性。其目标是讓每個應用軟體開發人員成為優秀的系統分析員，而不是代碼的奴隸。不用寫代碼便能生成各種各樣的應用程式。

xxx平台是一款企業級開發工具。可以非常友善，快速，高品質的開發各種應用系統，如CRM、MIS、ERP、資料倉庫、人力資源系統、資産管理系統、供應鍊管理系統……與傳統的編碼式開發不同，平台采用配置式開發。絕大部分子產品均不用編寫代碼，隻需通過平台進行參數配置即可，業務流程複雜的子產品，可以采用平台自帶的代碼生成器方式形成基礎編碼，對基礎編碼适當優化即可完成。

Xxx平台是真正針對不斷變化的需求而設計的面向構件的平台。它将構件技術、XML企業總線技術和可視化開發技術完美結合，通過圖形化的構件單元作為應用系統的基本組成元素，為企業級應用系統的開發帶來了卓越的價值。

Xxx平台為企業資訊系統建設提供了統一的公用基礎設施平台，采用“主機闆＋插件”的模式來建構和擴充業務系統，各類業務系統直接構架或連接配接到統一的協同業務平台上，并以其為基礎和樞紐，将分散的企業應用管理系統整合起來，形成一個有機的、緊密聯系的整體。這是一種全新的軟體開發和維護模式，是以業務描述、而非代碼為核心來建構資訊系統。業務模組化能夠真正實作 “快速開發、靈活調整、業務驅動、技術無關”，充分滿足“整體規劃，分步實施，自我掌控，随需而變”的企業資訊化長遠戰略規劃要求。

xxx平台是依據多年開發企業管理軟體的經驗，推出的一款業務基礎平台産品，它基于B/S架構，集OA系統、業務系統與開發平台于一體，提供了強大而靈活的定制開發功能，業務子產品無限擴充，涵蓋軟體的需求、設計、開發、測試、實施和維護等整個生命周期，可以通過網際網路随時随地通路與維護，代表了新一代管理軟體體系和開發模式。

web開發平台之疑雲

對于web開發平台，網上也有衆多的疑惑！

行業管理軟體，請把平台拿走。有什麼用呀。

簡單的修改，比如界面挪個位置，變個顔色。

中等的修改，做個複雜的統計報表，加個字段，改變個字段長度和類型，加個頁簽一個頁簽做錄入一個頁簽做查詢，加個浮動視窗來參照關聯業務，改變業務校驗規則。

複雜的修改，如當地有規定，如本企業由于曆史遺留問題必須這樣處理業務，你必須改變你現有的軟體，不知你辛辛苦苦費了很多高深技術做出了一個家夥能做哪些？

你做平台不就是為了修改快速好節約成本而導緻盈利嗎？否則要平台幹嗎？

但是如果一個平台，隻能做簡單修改，也就沒什麼用。如果一個平台連複雜的修改也能做，我覺得它肯定複雜的像PB、DELPHI、VB、JAVA、.NET之類了，那還幹脆不如用這些開發工具。這種平台食之無味，棄之可惜。隻是一幫鑽了一輩子技術也沒有混到主管位置上的高手們的一個技術夢而已。

你以為有幾個客戶能定義中繼資料，能自己關聯表做統計，能寫一段SCRIPT。

還不得你們客戶化中心自己做？

自己做，用自己的平台，還不如用順手的visual studio。

你想是不是這個理？

是以别吹你們有什麼ORMAPPING，OIMAPPING，實體對象，設計模式，平台。

就象咨詢師一張口就是業務流程重組、組織結構、企業戰略、績效考核、團隊激勵

别扯淡了，有本事把程式穩定了，修改及時，支援回答疑問負責任，真心解決問題，而不是敷衍。

你們的平台如果有本事做到程式穩定，高性能，修改及時，我也服了。就怕你們都嫌這個平台連visual studio都不如。

web開發平台在軟體投标過程中實作快速原型有幫助，但實際應用系統還是需要用大廠商提供的開發工具進行開發，假如一個web開發平台真那麼容易實作的話，而且那麼有用的話，為什麼微軟、IBM等公司不去做這樣的工具呢？

如果你的用戶端作業系統隻是一種，就是WINDOWS。那麼你大可不必學習新技術去開發什麼WEB版本。隻要軟體是小子產品的，有自動檢測更新程式的就可以。

什麼時候使用WEB?

1用戶端是各種各樣的作業系統

2客戶不願意用戶端使用VM

3應用的界面操作要求普通，不需要調用用戶端本地的硬體裝置和API

但是，這種環境，對于具體的每個國内做管理軟體的公司而言，這樣的客戶少之又少。

是以，用WEB做管理軟體，沒有意義。

web開發平台之深思

       當我們Copy代碼時，當我們一次次地重複編寫類似的代碼時，當我們一次次地重複編寫類似的控制時，我們都會想，下次把它歸一下類，省得每次改這麼多地方了；等有時間了做一個工具，直接用工具配置一下就可以，不用寫代碼了。久而久之，開發平台就水到渠成了。從這點上看，web開發平台顯然有其存在的價值，有其自然而然的需求。

       收入 vs 付出

無論是什麼裝置機器還是别的什麼東西，它到底有沒有用，作用有多大？主要取決于使用它的回報與付出的比例。如付出少回報大，則其作用大。Web開發平台也是如此。如果要将web開發平台用起來需要學習或适應很多新東西，而獲得的回報不大。則這樣的開發平台是沒有願意用的。是以說一個有意義有作用的web開發平台顯然應是需要學習的新東西要越少越好。而獲得的回報（即功能的強大性）要越大越好。而這兩者又是一個沖突。向左走還是向右走？這就象哈姆雷特的“生存還是滅亡”一樣，是個經典的問題。

       技術平台 vs 業務平台

       web開發平台是一個技術平台還是一個業務平台呢？技術平台是指由技術人員使用，業務平台是指由業務人員使用。如果web開發平台簡單易用（即需要學習的新東西少），則可以是業務平台。如果web開發平台功能強大，則為技術平台。

       顯然，web開發平台在易用和功能強大的夾縫中，左右徘徊。尋找中間的平衡點，是每個web開發平台的設計者所必須面臨的抉擇。平衡點在哪裡？抑或是有沒有平衡點呢？還是可以跳出這個兩難的魔咒呢？

web開發平台之定位

       和傳統開發工具(如visual studio)的關系

       顯而易見，web開發平台是不可能取代傳統開發工具的。應是在傳統的開發工具之上的封裝，即是實作了一些通用性的功能，當使用者需要這些通用性的功能時可以很簡單的調用，遇到無法滿足的功能時就要用傳統開發工具來寫代碼來實作了。

       什麼人來使用web開發平台？

       技術人員，業務人員（非技術人員），或是半技術人員（指懂些簡單技術的人）?還是一個web開發平台的有的部分是技術人員用的，有的部分是業務人員（非技術人員）用的?

       什麼人來使用web開發平台這個問題看似簡單，實則并不好回答，我甚至于覺得國内做所謂的開發平台的人或公司都無法回答得清這個問題，這麼說，并不是指他們（指做開發平台的人或公司）沒有想過這個問題，而是這個問題無法權衡清楚，常常是有時是這樣認為的；有時又想法變化了。比如業務人員（非技術人員）到底能接受得了什麼難度級别的東西？能接受簡單的SQL？或是能接受資料庫，字段，記錄，主鍵等概念？能不能用資料庫來規劃設計管理自己的業務資訊等等？

web開發平台之架構

一個web開發平台大體應包含如下東西：

1中繼資料設計

字段的資訊：如中文名稱，長度，資料類型，輸入方式等等；表資訊：表間關系，主鍵，外鍵，中文名稱等等。

一個單據，常分為主從兩部分。每部分的字段中文名要錄入進去，以為了界面設計。有些字段的錄入是參照字典的，哪些字段參照哪些字段，也做個關聯，這就是最簡單實用的中繼資料設計。

2單據設計

界面運作期動态拖拉的控件多的是，增加單據頭，還是細目，有了中繼資料就好辦多了

單據上的控件不外乎日期、文本、數字、字典參照、CHECK、GRID，

BUTTON、PAGECONTROL、TREE等等，這樣，就解決了客戶要界面變，錄入的字段要增加減少，驗證要改變的要求，控件的顔色、長度、限制條件、是否必填、中文名、跳轉順序，你可以存在表裡面，也可以儲存在表單檔案中。

3單據儲存

這個單據對的什麼主從表，有字典對照就可以了

主從表的送出和單表的送出，都很簡單，這很通用。

這樣錄入就完成了。但是，我們這裡還缺三塊的描述，一個是錄入和浏覽細目的GRID，一個是字典參照控件，一個是通用字典錄入。

4錄入和浏覽細目的GRID、字典參照控件、通用字典錄入

對于字典參照控件，肯定就是一個模糊檢索EDIT和一個檢索出來的結果顯示的GRID。

對于錄入細目和浏覽用的GRID，需要過濾、定位、列的排列先後順序，哪些列可視。這種功能，在單據錄入的GRID中一樣通用。

有時候錄入的時候發現字典條目沒有，就需要增加。這裡就用到通用字典錄入。

當然，你可以為每一個字典錄入做一個子產品。這樣：在錄入單據時也可以用，單獨調用也可以專門錄入字典。

每個字典錄入界面，在表中記錄好對應哪個字典表。這樣，在程式的任何地方，你都可以調用起這個視窗

輸入界面做完了，字典維護也完了，就剩下查詢和報表了

5資料查詢與報表

查詢條件千變萬化，但都在單據的可選字段之中。本質上就是用單據表中的某個列進行查詢過濾，結果輸出到GRID中。報表其實和查詢一樣，隻不過查詢是輸出為GRID。但是報表又分為普通二維表、交叉表、圖表、套打表、固定行清單、多源、關聯分片、不規則分組、自由格間運算。

報表的查詢條件設計和查詢一樣的原理。報表的設計需要單獨的設計工具。要在主程式中列印預覽報表，也要能調出查詢條件，能将報表結果導出為Excel pdf 等檔案。

6工作流，內建工作流引擎，能夠對業務流程進行靈活的定義。業務流程定義的結果以中繼資料的方式儲存在資料庫中，運作時由工作流引擎根據中繼資料的描述驅動，業務單據都可以通過工作流進行驅動，進而實作業務流和資料流的統一。

7基座

輸入輸出都有了，就應該有個基座把這些功能都裝進去，而且要根據每個人的登陸權限動态裝入，基座的作用就是驗證使用者登入是否正确，從伺服器上取回使用者的配置資訊，根據權限配置設定，建立使用者功能菜單，點選菜單的時候就裝入子產品。

8組織結構設計、權限配置設定

組織結構設計：需要有集團-公司-部門-人這樣的維護界面。人又歸類為一些角色。角色包含角色特有的功能。這樣你在配置設定權限的時候，就非常容易先給一個人配置設定一個角色，這樣标準功能就都有了，如果這個人還有特殊性，就個别再增删功能。角色也有高低，這樣在使用同一個子產品是，如查詢我手下所有人的工作單。我是小組長，我就隻能看我這個小組的人的工作單，我是科長，我就能看所有小組長，包括各組下的普通員工的工作單。

而權限，這在架構上很有要求。權限配置設定分為三類：

業務功能權限配置設定，要能配置設定到這個子產品的每個按鈕功能及子功能，大多數普通的管理軟體，隻能到子產品。一個子產品，不同的人使用應該有不同的權限。有人就能看，有人就能删除，有人就能修改，有人就能增加。而且更特殊的是，科長能錄入負值，其他人不能錄入負值。這些很細的功能權限都要配置設定到。字典權限的配置設定。有人就能看，有人就能删除，有人就能修改，有人就能增加。報表權限。有的人能看這張，有的人能看那張。更深入的是：有的人能列印這張，能導出這樣。有的人不能導出資料。

管理，管理，就是定規則，然後執行。是以權限是定規則過程，執行就是日常使用了。

9還有一些公共業務函數和使用公共資料庫連接配接池，就放在公共子產品中，讓普通業務程式員調用。做OpenApi，開放的web服務，供外部實作mash-up（一個網站或應用程式，将來自多個随需應變平台的工具組合起來建立新功能）。

10還有一些外圍的功能，如軟體加密，導入使用者以前的資料，安裝資料庫而不是恢複備份，标示這個軟體是什麼版本打了什麼更新檔，這樣在追查錯誤時比較容易判定是什麼版本。

還有一些，就是登陸日志記錄，軟體操作錯誤就把錯誤記錄下來，把界面螢幕抓下來。

當然，如單據審批工作流，單據回溯追單一查到底關聯查詢，如短信的結合，如單據确認消息發送，這些都是外圍的一部份，但卻是很重要很實用的功能。

web開發平台之實戰

       如何開始着手實作web開發平台，一般是從常用控件的開發時起，比如開發：tab頁控件，dropdownlist下拉清單控件，表格grid控件等等。等控件做得差不多了，就需要一個可視化的設計界面來用于布局這些控件了。這樣做下去了，便成了我做的eform自定義表單工具了。

自定義表單工具用于完成表單界面的設計，布局。對資料庫中的資料實作增加，修改，删除，查詢。它可以在投入使用的同時進行開發，開發和使用即在一個平台上卻又互不影響；這一特征使得軟體可以更快的提供給客戶使用，進而更好的适應客戶需求變更；同時為軟體維護和變更帶來革命，作為維護人員你再也不需要客戶、公司來回的跑啦，現場就修改吧。它最大的特點是表單修改後無需編譯就可運作，表單設計器也是web頁實作的，無需下載下傳插件，可視化設計，控件豐富，包含：button,label,textbox,combobox,listbox,radio,checkbox,textarea,div,超級連結,頁簽,dataset,img,shape,checkboxlist,radiolist,dbimg,upload,table,grid,dropdownlist,spin,tree等等。詳見：http://www.fcsoft.com.cn/eForm.htm

         除了表單設計器之外，還有一個非常通用的就是報表工具。對于報表工具我是用e表來實作的，e表分e表 for .NET版和e表 for Java版，分别用c#語言和JAVA語言實作。用e表來實作複雜的統計報表。它采用類Excel報表設計器，通過多源、分片、不規則分組、雙向擴充來輕松拖拽做複雜格式的報表，做報表從此不再需要編寫複雜的SQL語句和做大量的前期資料準備了，不僅不需要程式設計而且大大降低了報表後期的維護量，将制作報表的效率提高了一個數量級，徹底地解決了困擾中國報表領域十多年的難題。詳見：http://www.fcsoft.com.cn/webreport.htm

       除這兩個之外，還有象工作流等等暫時我是沒有時間和精力去研究了。

web開發平台之頓悟

       它山之石，可以攻玉。還是來看看salesforce的web開發平台吧！在《建立随需應變的應用程式：Force.com 平台簡介》中主要說明了web開發平台實作一個招聘程式的過程。

       定位給業務人員使用的。對技術要求較低。不過，我想在其内部一定有一層清晰的開發平台。也就是說，其實質是用兩層平台來分别應對簡單易用和功能強大性。這兩層平台之間又是互相聯系的，即面向業務人員用的這層平台很可能是由背後的平台生成簡化而來的。如下圖所示的兩層平台，分别應對簡單易用和功能強大性。

       由此可見，先有一個功能強大的開發平台，由它來應對複雜的功能。然後由此生成簡化一個面向業務人員使用的平台。由這兩層平台同時提供給使用者使用。同時使用在一個應用中。業務人員用簡單易用的平台來完成一些基本的功能，技術人員用底層的平台來完成複雜多變的特性。再輔于開放的api，web服務供外部內建。這似乎是一種圓滿的web開發平台解決方案也未可知。

Web開發平台一旦用起來了，可以很大的提高團隊開發的效率。等大家實作了，你會發現，你給了程式員業務描述說明，裡面包含要寫的表和界面和功能操作說明，給了他資料庫結構說明，資料庫設計員寫好SP和VIEW，普通程式員很快就能做出一個功能和改變一個功能。如果再加上這個普通程式員寫的代碼風格統一規範，小函數封裝，界面和功能分離，即使沒有什麼OO和UML，這個産品仍然容易定制和修改。作為一個技術架構師，就是提供工具和公共功能，并且聯合資料庫設計師或自己合并擔當資料庫設計， 使軟體就高性能、穩定、安全、可裁減修改。一個軟體的終極目标不就是這些嗎？如果這些都實作了，普通程式員的地位又是怎樣呢？項目經理負責進度和業務描述和品質、架構師負責上述架構、普通開發人員和測試人員保證産品出來、售前售後教育訓練人員調研客戶需求教育訓練人員、普通實施技術人員和普通支援人員做好支援。一個夢之隊就産生了。中國的軟體公司大部分都是50人以下，UML、OO、模式、軟體工程，都是不現實的。從目前來看，不乏項目經理，也不乏架構師，因為一個開發團隊，隻需要一個項目經理和一個架構師。而目前中國軟體業特别需要普通程式員。但是很低的工資很少可做的工作，對于大學畢業的大學生來說，這簡直就是浪費人才。但是，沒辦法。就像傳統行業，現在特别缺技術勞工，農民工太低，城市下崗人太老，大學生不願意下工廠中的房間，但是沒有人願意上職高和中專。這就是現狀，你不接受也得接受。你接受不接受？我們唯一能做的就是利用現有的資源，把事情做到最好。中國人的奇迹一般都是這麼創造的。

web開發平台之明天

毫無疑問，在不久的将來，web開發平台将依然在迷霧中前行。依然會有一批批執着的程式員抱着各種各樣的美好夢想投身進來。幾十年了，人月神話依然是一個神話。或許，這也象是永動機一樣是個無解之題。或許，這隻是看上去很美而已，永遠無法落地成為真實。或許，它挑戰了人類的極限，引來了上帝的笑話。

在社會分工越來越細的今天，想讓業務人員來搭建自己的資訊系統，這個方向本身就值得懷疑。當然，在中國，懷着各種各樣目的，編造不可能實作的慌言，來蒙騙不懂得技術的人，這似乎成了一種主流。從早期的ERP到當今如火如荼SOA。使得使用者不得不察亮雙眼，來尋找自己的真正需要。

隻要能真正提高程式設計工作的效率，就會受到使用者的青睐，就會有持久的生命力和存在的價值。

轉自:http://www.cnblogs.com/webreport/archive/2008/05/07/1186255.html