一篇偏激的項目總結和PPT——數據驅動型的網站開發的幾個問題和討論。

    所謂數據驅動型的網站，其實就是常見的MIS系統在B/S形式下的實現。B/S模式在90年年代末大量出現的時候，其主要特徵是Page-Based，也就是基於頁面的。由於Html技術的網站自己是一張一張的頁面組成的內容展現工具。對於MIS系統的比較複雜的高速交互式的操做，用本質上不是很是兼容。

從1995年到2005年的十年間，全部人都在與兩大不兼容問題進行鬥爭，編寫了無數無任何意義的代碼，尤爲是以Java最爲甚。

第一個不兼容是ORM，也就是關係對象映射，95年之後，是面向對象程序設計大行其道的時候，Java也是標榜本身的原生的面向對象特質。可是，MIS系統操做的數據，是關係型數據庫，其存儲在數據庫中的數據形式，是以表爲形式的。因此絕大多數Java的項目，都將表直接映射爲一個對象，對象裏面只有get和set方法，這種對象唄成爲POJO(Plain Old Java Object)，也就是貧血的老舊的Java對象,而後所謂的海量的DAO代碼，不斷的將各類表對應到POJO的對象當中。

後來出現了hibernate，經過xml配置，將對象和表進行了所謂的快速綁定。

可是hibernate存在兩個問題，致使其使用很是受限。

首先hibernate的性能極差，使用hibernate的Java項目的性能會降低十倍左右，並且hibernate採用反射的方式構造POJO對象，POJO對象的特徵是大量的產生大量的銷燬，在一個用戶一次網頁的數據訪問過程當中，至少會生成10個POJO對象，若是一個500併發的小型業務系統正常運行1個月，將會用反射建立13億個POJO對象。而Sun的Java虛擬機存在一個特性，其系統容納的類的信息，在運行時，都放在permGen內存區域當中，有一個類，佔據permGen一點數據，而在反射的時候，實際上是現場編寫了一個新的類（反射代理類），因此每一次反射，就會佔據PermGen的內存的一小塊空間。假設一個代理類只佔一個字節，13億個對象，也就會永遠佔據1.3G的內存。雖然能夠經過調整JVM的permGen內存大小的方式，保證系統能多運行一會，可是在正常的業務系統中，平均1到2個月的宕機幾乎是沒法避免的。

其次，hibernate的關係映射並不徹底覆蓋掉全部的關係型數據庫提供的功能，不少關係型數據庫提供的功能，在hibernate的對象關係型映射，其中並無充分的實現，不少複雜的SQL幾乎不可能改寫爲hibernate的HSQL和關係映射。因此不可避免的在存在hibernate的系統中，容納很是多的jdbc直接讀寫數據庫的代碼。容易形成事務性和代碼維護的困難。

第二個不兼容，也就是業務系統的需求和網頁這種交互形式的不兼容。傳統的html網頁，並無提供充分的交互能力，因此採用B/S模式的MIS系統，缺少真正的獲得用戶讚揚的案例，在日本，你們用的Excel實現業務的功能，在歐洲，SAP的客戶端軟件大行其道。用網頁作的業務系統，常常被詬病爲打開慢，沒反應，不人性化。根本緣由就是交互的時候頁面經過form不斷的提交，刷新，不符合人們內心對軟件系統的預期。

在客戶端裏面輕鬆實現的Excel式表格操做，Word式排版，公式，複製粘貼，報表，打印調整，實現都很是困難，實現了也只是一個樣子，應付用戶的初期審查。

此次的項目，咱們也是針對這兩個問題，奮戰不息。

其實，在解決這個矛盾的過程當中，其實微軟的C#，早在2003年就找到了相對正確的解決方案。

微軟基本思路以下：

不對面向對象進行生搬硬套，用ADO對象的DataSet來處理表，表就是表，沒有必要轉化爲對象進行處理。

交互方面，採用大數據量的view_state隱藏字段，儘量的本地響應用戶的操做，儘可能模擬用戶在桌面端的體驗。可是因爲當時尚未Ajax技術，這種提高效果有限。

而Java社區，沒有很好的處理好這兩個問題，致使不少Java的市場份額，被PHP佔據。PHP主要就是在數據綁定方面，直接將表的暴漏給前端，而後用模板的方式進行解析和組裝。交互方面基本放棄了MIS系統的開發，全面轉向內容型的互聯網服務。

項目的模式

Java的項目目前主要有三種開發模式

1.採用三層架構，用Spring+ORM中間件+前端框架實現業務系統。這種開發模式的有點是代碼很是面向對象，便於管理，容易閱讀，功能清晰。缺點是性能極差，學習成本比較固定，上手須要3個月左右，須要比較系統的培訓，受限於系統特性，致使功能比較弱，用戶使用感受不流暢。對於事務管理方面，粒度過低，要麼就都加事務，要麼都不加，雖然能夠配置可是配置文件很是複雜。大多數Java的項目都是如此開發的，多數都實際上失敗，缺少用戶的足夠好評。

2.採用Servlet，Servlet直接使用JDBC，由於原生的JDBC進行ORM很是複雜，會產生大量的冗餘代碼，可是開發成本低，學習曲線低，開發的系統很是穩定。實現的功能每每比較強大。少數成功的Java項目，都是採用這種模式進行開發的。

3.第三種模式，參考微軟的思路，不採用面向對象來映射數據，而是直接將表暴漏給前端。這種的問題是隻適合實現內容管理的MIS系統，並且Java社區，對此思路嗤之以鼻，所以幾乎沒有這種實現組件，若是用Java實現此模式，就要實現一個Java版本的.net Framework的數據鏈接組件部分。

此次的項目，主要選擇了第二種模式，項目啓動階段，主要考慮到咱們人員對Java瞭解不是不少，若是直接用第一種模式，須要你們先放下全部工做，去從Struts，Spring，Hibernate進行學習，若是學習到獨立開發階段，樂觀至少須要1到2個月的時間。學習的主要內容是配置文件的思路。並且在開發時，因爲你們都依賴於兩個配置文件。在協同過程當中Struts.xml, applicationContext.xml不可避免的發生衝突。

第三種模式，走不通是是由於開始的時候需求並不明確，不能徹底確認這個系統就是對錶的操做，並且實現ADO的組件難度很是大，項目風險很是高。

所以，選擇了麻煩而又穩妥的第二條道路。