理由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是啥概念？沒有用小機跑，整啥也白瞎，是吧....也不知道這位磚家見過小機沒有....
為什麼要選擇ISP 為什麼要選擇AHD
在影象傳輸中，我們為什麼選擇nextchip?為什麼要選擇isp?為什麼要選擇ahd?為什麼選擇北京冠宇銘通？這個問題我倒著回答各位 一 北京冠宇銘通科技是nextchip目前為止唯一一家正式官方授權 車載產品廠家之一 二 ahd和其他幾種傳輸方式相比，擁有自己的專利，其他幾家有專利的沒有幾個，如果...
為什麼選擇discuz
使用disczu是在幾個月之前，那時候剛接觸php，之前還不知道大部分論壇都是用的類似discuz這種系統直接安裝的，還以為都是自己寫的程式呢.剛學時，什麼也不懂，只是感覺挺好玩的，不知道啥叫使用者體驗，不知道啥叫模板技術，更不知道啥叫快取技術.隨著學習的深入，對discuz由原來的使用變為了研究。...
為什麼選擇svn
svn的幾大好處 1 svn版本號是以自然序列遞增的，大家都很容易明白，所有的人以統一的方式運作，不會有太多模式。2 svn版本庫看起來就像乙個本地檔案系統，你可以自由地檢出子目錄。3 svn容易使用，學習成本比較低。4 svn成熟度高 5 更適合和二進位制檔案管理 檔案鎖定和部分檢出 svn的乙個...