Asp.Net大型項目實踐-關鍵技術方案選擇理由及思路

雖然我不喜歡討論太多理論概念上的東西，但各位“磚家”還是提出了很多非常有針對性的意見，望此帖不要成為口水戰才好....現答疑如下（有很多個人理解，不一定正確）：

磚家意見請參見：Asp.Net大型項目實踐系列導航

為什麼選擇NHibernate

理由1：對象關係映射技術（ORM）的最主要目的是為瞭解決關係型資料庫與物件導向編程技術不匹配的阻抗問題，何為阻抗？通俗的說物件導向的類往往都存在繼承和類間關係與資料庫的表不是一一對應的，ORM技術可能主要是想解決這個問題。這裡需要說一下好多同學和磚家在用ORM的時候還是喜歡先建表，再工具產生和表欄位一一對應的所謂實體，個人認為這不是O->R M,而是R->O M,實際上這種做法完全沒有體現ORM的最關鍵思想，還是以前的“表驅動”（通俗解釋：先設計表）而非“業務領域驅動”（通俗解釋：先設計真正物件導向的業務實體）。因為我的系統業務比較複雜多變，我希望我能儘可能的隨心所欲的按照物件導向的思想去設計我的業務實體，充分發揮物件導向思想的作用，不用關心這些設計是否能被持久化，顯然NHibernate讓我做到了這點，這是我在項目中選擇使用ORM技術和NHibernate的最主要目的。

理由2：通過NHibernate和我們的合理設計，實現了對團隊人員在開發的時候屏蔽掉資料庫訪問的技術細節，讓我們更專註於業務和UI實現，在絕大多數情況下（複雜的報表查詢和大大量操作依然可能需要預存程序實現）不必去關心SQL語句之類的，這對於一個絕大多數都是資料庫操作的資訊管理系統來說無疑具有很重要的意義。任何一個技術解決方案都不可能覆蓋100%的需求，能用20%的精力，解決90%的問題就算是很成功了。

理由3：因為這個系統並不是只給一家醫院使用，不同醫院所使用的資料庫產品是不一樣的。從工程角度不能強制要求客戶使用固定的資料庫產品，NHibernate很大程度上屏蔽了不同資料庫產品之間差異，使我不必對不同資料庫產品分別寫具體實現。

關於效率：“效率YY磚家”說：NHibernate效率低；“大型系統磚家”說：如果並發1W，NHibernate玩不轉；弦哥說：

NHibernate這個技術本來長項就不在效率，而在以上3個理由（也許還有一些..），拿NHibernate和直接Ado.Net比效率就像拿c#和彙編比效率一樣可笑。

Hibernate+Spring在J2EE裡長期作為教科書式的解決方案，無論在國內還是國外都有非常多的大型系統成功案例，從這個意義來說也許Hibernate在效率上並非如此不堪，怎麼到了.Net這邊就成了效率低下的代名詞，貌似說到Hibernate，各位磚家就以效率低一棒子打死，嗤之以鼻。

對於NHibernate的效率弦哥也整了些典型的情境和類比資料用LoadRunner測了下，並非有各位磚家說的那麼誇張，請問各位磚家測過沒？

效率問題是一個複雜而綜合的問題，如果忽略項目背景，實際業務需求，技術實現方式，以及多種軟硬體因素的影響，片面的YY效率無疑是非常不嚴謹且非常可笑的。弦哥做所謂大並發，大資料量的電信，銀行項目也有一些，對於這類項目上線啟動並執行效率瓶頸幾乎都在IO，往往都是通過Oracle最佳化專家和硬體方式解決。比如像上面那位“大型系統磚家”所說的1W並發的項目，同時並發1W是啥概念？沒有用小機跑，整啥也白瞎，是吧....也不知道這位磚家見過小機沒有....

為什麼選擇EXTJS

理由1：客戶對UI互動要求非常高，又要求用B/S結構應用程式，Ext超強的UI組件互動能力正是我需要的

理由2：物件導向的Javacript編程，組件化編程，相比用以前的第三方伺服器控制項來說，可維護性，可讀性和編碼體驗不知道要好多少...

理由3：由於客戶對UI互動要求非常高，不用第三方UI組件是不可能的了，用第三方最大的風險是遇到Bug和內建功能不能滿足的需求，ExtJs的開源和良好的物件導向能讓我方便的重寫源碼實現任何我想要的功能。

理由4：我是內網系統，無需理會苛刻的網速問題

理由5：不可否認，在競標或推銷的時候美觀的介面和互動對客戶的好感度有相當大的影響。用EXT大多數情況下，我無需關係任何美工，Css，Html等煩人的細節

理由6：對於非常複雜的頁面以及大表單頁面，Ext在IE下確實有點延遲（這個效率問題的瓶頸是在用戶端），所以我們在實施的時候都給客戶用Google瀏覽器，涉及到醫保的ActieX用除外（用google瀏覽器的IETab外掛程式即可），Google瀏覽器下Ext的表現讓人非常非常滿意（V8引擎真強悍呀）...就算是很複雜的互動和大量組件存在於一個頁，互動操作基本都是瞬時的

任何技術解決方案都不是銀彈，ExtJs也不是UI解決方案的銀彈，沒有最好的技術，只有最適合你項目的技術，不知道各位“磚家”還有啥理由讓我不用Ext....

為什麼用依賴注入（具體用Unity實現）實現層間調用

因為醫院資訊系統業務比較複雜，雖然是產品化開發也做了很多參數配置，但在具體實施不同醫院的時候，難免會涉及到修改代碼。

在實施改代碼的時候我希望做到兩點：

一.在不改變原有產品發布代碼版本的基礎上去修改代碼；

二.因為可能同時有幾家醫院使用者，如果一家醫院一套代碼勢必會增加公司的運營成本和管理難度。

所以我們在遇到需要修改代碼的時候，建立一個檔案（類）去繼承產品發布版本代碼的具體實現，並根據情況重寫。這樣我只需根據不同業務，不同醫院修改設定檔即可

當然如果遇到因需求變化需要變更介面，那也沒有辦法了..不過因為HIS業務我們有10多年行業經驗，所以在產品開發的時候對於業務都能考慮覆蓋到。

當然需要說明的是在本項目中依賴注入並不只是應用在層間調用，依賴注入設計模式適用的業務情境我們都可以用它來實現解耦。

相比原廠模式，依賴注入容器有很多優點，如自動裝配，執行個體對象的生命週期管理，可以傳參數等。

為什麼選擇Asp.Net MVC+ExtJs

待續...

更多技術方案選擇理由及思路待續...