平臺現在無疑已經是一個用濫的概念。先來看看業務平臺的定義：是為企業提供的一個可快速開發的、穩定的、成熟的業務基礎開發平臺。實際上在一個技術人員的眼里，平臺=類springside的開發框架+一套組織機構+和組織機構相適應的一套權限系統+門戶+信息資源庫+工作流引擎+一些通用的業務模塊。因為一直做關于所謂業務平臺的開發，有過困惑也有思考，這里說說自己對于平臺的一些想法，也希望大家多多拍磚。我認為一個好的業務平臺應該做到下面的幾點：
1、業務性。
   這個問題我曾經和胡長城有過很長時間的爭論。最后我得承認胡兄的正確性：業務確實是一個平臺的根本。一個業務平臺如果不滿足業務的需求，那么它存在的意義就值得懷疑。一個很簡單的例子，協同辦公中不可缺少的發文管理，正文需要用到電子簽章，業務中有這個需求，平臺不支持，那么這個平臺就不是個好的業務平臺。
2、易用性
   業務平臺不是面對最終用戶的，它需要做二次開發。這樣平臺對程序員的友好性就相當重要，畢竟平臺的使用者還是程序員。
   基礎代碼生成是必要的，不管你采用何種方式，是根據已有表格來生成模型和相應代碼還是先畫出模型再來生成表格和相應代碼（所謂的MDA）。平臺的代碼結構最好能夠和IDE有個良好的結合，因為項目的開發往往是幾個程序員協作的過程，平臺對代碼開發的支持不可能做到IDE的水平。最好的方式是生成的代碼自動在IDE里有著清晰的結構，在IDE里編輯、測試自己的代碼，然后自動發布到平臺相應目錄中，啟動平臺，代碼運行成功。eclipse插件是個很好的選擇。
   良好的API的支持，開發中不可避免的會與平臺已有的組織機構模型和權限系統交互，這樣良好的、封裝清晰的API支持就很重要。
   頁面組件的支持。往往有時候凌亂的WEB頁面最讓人頭疼。對常用的一些頁面元素可以用標簽或是AJAX做進一步的封裝。比如樹組件、彈出層組件、分頁組件等等。與這些相比，一些業務頁面組件的封裝也很重要。比如需要在頁面選擇用戶，直接封裝出一個用戶選擇組件，而不用開發人員在頁面用彈出層+用戶樹自己再去組裝。再比如說發文中的簽批意見，可以用AJAX直接封裝到頁面里，不用用戶自己調用相應API。意思就是讓用戶開發盡量簡單，把工作從代碼里盡量推到頁面上去。
3、模塊化。
   盡管這個或類似概念（比如說組件、構件）一再被平臺廠家們提及，我對實際的實現一直報懷疑的態度。實際的實現往往是對模塊的一個模擬。這里的模塊實際上是對代碼做出的一種人為上的區分，所謂的模塊配置，更直接一點就是頁面URL的配置。與代碼行為無關，與運行期管理更沒關。
4、可擴展性
   這個暫且不說，很大的一個話題。
5、前瞻性。
   一個優秀的平臺憑什么和別人不同，一個很重要的一點就是平臺的前瞻性。一句話，就是要有別人沒有的東西。個人非常看好未來對業務整合的需求，遺留的業務系統+國外大廠商的概念轟炸讓客戶開口就是業務整合、BPM。是時候不再忽悠而是做點實際的東西了。
可以說，業務性+易用性在現階段就是一個很好的平臺了。如果再有些前瞻性的東西（注意：不是口頭上！）這個平臺應該說很優秀了。至于模塊化、可擴展性，想想，現在只能說忽悠了。


http://m.tkk7.com/ronghao 榮浩原創，轉載請注明出處：）