最近找工作面試，問到一些過去的工作和項目經驗。我把公司用到的ORM框架(LLBL Gen)拿出來談一談，說一下他的優勢，對方卻一直追問ORM的好處，性能方面的問題，讓我有時候都不知道如何回答，產生了不小的壓力。
坦白來說，自學生時代(2004)就對NHibernate的大名敬仰已久，也完整的學習過它的映射文件寫法，數據讀取方法，當時對復雜的Xml映射配置文件了熟於胸。那時，微軟的Application Block還比較流行，這項技術演變為后來的Enterprise Library，在第二份工作，我可以參與技術選型時，毫不猶豫的選擇了Enterprise Library。再配合一個實體代碼生成工具，工作中的技術需求都可以應對。再接下來的一份工作，選擇ORM數據訪問，再應用一些熟悉的技術，一下子對整個MIS類型項目的開發設計有了更基礎層面的理解。如果需要了解，請參考
Enterprise Solution 2.2 開發幫助文檔集合
ORM到底有什么好處，以我的理解有以下三點
1 強類型的對象 界面和業務邏輯層以實體對象來作為傳輸格式，編譯器在編譯時就可以輔助幫忙檢查類型錯誤，而不需要等到運行時。
2 借助於數據綁定技術，業務邏輯層與界面層完全分離。ASP.NET MVC現在是教導你強制分離，並且創建好了基礎結構，只需要遵循它的開發模式，即可開發出界面與邏輯分離的程序。但在WinForm時代，我承認，在之前，我是用很原始的方式，在窗體加載(OnLoad)時把數據綁定到控件，在點擊按鈕執行動作時，再從控件讀取數據，傳到邏輯計算方法中。強類型配合數據綁定技術，在界面加載時，傳遞一個entity到界面中，在執行動作時，獲取數據源中的entity，可以節省大量的代碼。
3 可擴展性，可維護性增強。如果有數據庫字段修改，因為傳遞的是entity對象，數據訪問接口不需要做任何修改，而界面中只需要把相關的字段綁定到控件中即可。MIS類型的項目，表格或字段的增加與減少是常有的事，而需要做的就是重新生成一次實體定義代碼，綁定字段到界面中，增加需要的計算邏輯即可。
因為ORM框架會自帶一些基礎的類型(元數據)和數據訪問方法，因而還可以做出很多基礎性的工作。舉例如下：
1 插件式系統的功能管理。管理基礎的模塊和功能。
2 定義一套權限結構。用戶管理，用戶組別管理，模塊權限，功能權限，具體的數據字段權限與業務綁定。
3 定義一套查詢框架。MIS類型的系統，在系統提供基礎查詢的基礎上，要讓用戶可以自定義查詢。在這點上，只需要獲取ORM的entity與數據庫中的table映射關系，放到基礎的查詢表中，再依照此實體，反射它的屬性成員供用戶選取查詢，最后生成一個查詢表達式，運行時轉化成SQL語句從數據庫中讀取數據。
4 定義一套報表框架。因為報表是經常會發生變化的。報表的布局，參數，數據來源，計算邏輯都會依照實際的需求產生一些變化。程序員需要將報表開發中，不會改變的地方獨立出去，做成一個公共模塊，供報表開發人員調用。這一塊內容，我做到了將用戶輸入值與與報表參數動態綁定。
5 導航設計工具。MIS項目如果要滿足用戶自定義菜單，導航功能的需求，則需要實現一套菜單結構定義。存儲的格式為Xml或是數據庫，在運行時，依據定義生成界面中的菜單和導航，增加靈活性。
6 工作流綁定。因為強類型的entity，它的create,delete,update動作都可以通過讀取元數據得知，包括屬性值的變更，以反射的方式讀取。可以截獲特定的值改變事件，比如采購單批准(approved)這個值設為yes，激活工作流，自動生成一些數據通知或查詢結果，發送到指定的負責人。
性能層面，ORM肯定不及原生的ADO.NET，映射轉換從entity到table都需要消耗一定的時間。經過優化的ORM查詢，性能損失不比ADO.NET慢很多，但是得到的好處是易於維護，以及因此而帶來的一系列的技術提升，前提是你不僅僅把ORM拿來做數據訪問，還研究它的元數據結構，與數據綁定技術的融合等技術。
四年以前開發MIS類型的項目，從創建數據表開始，再借助於代碼生成器，生成實體和數據訪問代碼，再到邏輯層開發。在經歷上一份工作之后，經過這幾年的積累，我也做到了快速開發，不過這次的格調也高很多。用企業架構模式中的話來說，前一種是事務腳本(transaction script)，后一種是領域模式(domain model)。
最后寫兩句話與大家共勉勵：
1 適合完成項目的技術是最好的技術，一味追求技術更新會給項目帶來風險。
2 當你在習慣於一種開發模式后，在有精力或是項目允許的情況下，可以考慮嘗試另一種技術路線。