.NET的WEB商業應用架構所要解決的若干

問題（轉載）

微軟風風火火地發起了.NET革命，至今已經有4年的時間了，就從其本質的CLR和C#文法上來說，確實比J2EE要進步不少，連Martin Flower在舉例說明OO方法時，都不自覺地使用C#來表達。然而若從商業應用的角度上來講，微軟卻落後J2EE太多，這主要是從商業應用架構上來說。J2EE由於老主宗SUN公司相對弱勢，導致不能很好地控制局面，因此J2EE陣營在發展初期經曆了鎮痛，但終於依靠開源來達到了空前的盛況，J2EE陣營注重標準、開放、良好架構的原則，並且現在也開始從微軟最擅長的易用性向.NET發起攻擊，J2EE對於.NET的優勢恐怕要持續地保持下去了。反觀.NET陣營，商業氣息濃烈，由於微軟的強勢，導致任何的民間組織都倍受壓力，微軟的發展或者說插入點是從易用性出發，從一些hello world或者petstore的小項目來說，確實有不少優勢，彷彿任何的項目都可以在彈指間完成，然後對於大項目事實上是這樣的嗎？微軟的這些易用性通常靠滑鼠點擊來產生hard-code的代碼，從重用性、維護、擴充角度上都要要付出巨大的代價。微軟陣營習慣了去使用微軟提供的API來完成項目，.NET陣營的特點是封閉、寡頭執政、易用。從微軟現在的情況看充其量只能在CLR和C#（JRE，和JAVA文法）或者說基礎架構上對J2EE有較大優勢，但是說到上層的OR-Mapping、表現層架構、AOP架構等，微軟幾乎無招架之力，而這些就是構建商業應用所最需要的架構，在很多.NET項目中很多的這些商業架構都是靠項目組自己來完成，其痛苦不堪而言。.NET和J2EE之爭，彷彿就是6萬人組成的嚴密組織紀律的高素質專業軍團和幾百萬人組成的民間機構體制的競爭，是從“易用性->架構”和“架構->易用性”的2條路線方針的競爭，孰勝孰敗，只有靠曆史來評判了。

突然發現我扯遠了，呵呵！也無所謂了，突來興緻多說點廢話了，全當在.NET這個陣營裡面生活太久的一些牢騷了。下面我言歸正傳，來談談.NET商業應用架構。首先，我想表達一下，為什麼要有提出這個商業架構的問題，我想解決的是什麼問題，總得來說商業架構所要解決的是：提高軟體品質、加快開發效率、降低維護成本。下面就從商業應用的各個方面來說明：

1. OR-MAPPING：我認為這是首要解決的問題，是整個商業應用中最需要提高的部分。有了OR-MAPPING，可以將以資料為中心的開發方式轉移到以Model為中心的開發方式。不解決這個問題，永遠也實現不了在《公司專屬應用程式架構模式》一書中所說的三種基本模型種的最高層次Domain Model模式。不解決這個問題，3層公司專屬應用程式中關鍵層次商業邏輯層的OO就不得執行。
   
   問題：要求實現商業邏輯和持久化的解耦，項目要求可以跨資料庫。
   
   可能的解決方案：NHIBERNATE（現出於beta版本）、IBatis（1.0版本）
2. 複雜查詢：OR-Mapping不能解決複雜查詢的問題，用NHIBERNATE中的HQL也不能很好解決這個問題（若查詢牽扯到子物件，必鬚髮送額外的查詢語句，以及OR-Mapping中的entity不能完全容納查詢所需的欄位）。
   
   問題：各種商業所需的複雜查詢實現需要動態構建很多查詢語句，不能很好的統一，也不能很好的維護。
   
   可能的解決方案：IBatis（1.0版本）
3. 資料字典：或者說meta-data，即描述資料結構的結構
   
   問題：很多商業項目要求可自訂欄位，自訂報表，自訂查詢列表等功能。另外，商業項目中很多查詢條件、列表的代碼過多重複。
   
   可能的解決方案：暫無，不過可以參考MSCRM中的meta-DATA的實現。
4. MVC：
   
   問題：不用說了。
   
   可能的解決方案：MAVERICK.NET、UIPB
5. 事務：
   
   問題：
   
       1、資料庫的事務不能實現business transaction的功能，要實現required、nonsupported、supported、等形式的事務功能。
   
       2、開啟事務、提交事務，復原事務的代碼過於重複，靠人為約束來實現難免會引入bug。
   
   可能的解決方案：Enterprise Services  （COM+）（但是將引入難以部署的問題）
6. 統一頁面中的資料驗證、讀取、和載入
   
   問題：很多頁面的資料驗證、讀取、載入都類似，但重複地寫過於繁瑣。要求如日期、金額等格式在整個項目中統一，開發人員在每個頁面中做同樣的繁瑣操作不利用維護。
   
   可能的解決方案：無
7. 日誌：
   
   問題：在每個商業應用中，都要寫很多類似的日誌代碼，過於繁瑣。
   
   可能的解決方案：Spring.NET、Aspect#、EDRA
8. 許可權驗證：
   
   問題：在每個商業應用中，都要寫很多類似的許可權驗證代碼，過於繁瑣。
   
   可能的解決方案：Spring.NET、Aspect#、EDRA
9. 解決並發衝突：
   
   問題：在WEB開發中的並發問題尤其嚴重，每個頁面都可能並多個使用者同時開啟，架構要處理這種並發問題。
   
   可能的解決方案：《公司專屬應用程式架構模式》中的第6章描述。