Entity Framework和NHibernate是當前.NET里最強大的兩個ORM框架，一個是微軟官方出品，一個是開源項目代表之作。我在09年用過EF 3.5，在最近的一個項目里在使用NH，雖然無可否認這兩個ORM框架功能都當強大，然而我在使用過程中還是覺得許多需要吐槽的地方。
首先說說EF，其實我最早接觸的是Linq To SQL，但由於當時項目的后台數據庫是Oracle，而Linq To SQL只支持SLQ Server，所以它立馬被否決，而其它的開源框架，一是我沒有用過，不熟不敢用，二是使用Linq To SQL有一段時間了，linq用得很爽，很上癮（相信用過的童鞋都了解），所以瞄中了這個微軟剛剛出爐的EF。這個EF雖然號稱支持多種數據庫，但是微軟仍然只內置了SQL Server的Data Provider，由於EF剛剛推出，Oracle官方還沒有提供只能對EF的Provider，好在微軟自己在codeplex上以Oracle 10g，11g為例，發布了一個針對Oracle的EF Data provider的示范性的開源項目。經過一番波折，總算用上EF了。在使用過程中，也發現若干不便之處，太多細節之處也記得不清了，這里列舉一二。一是實體模型，即那個edmx文件，每次數據庫對表或者字段作了改動，都需要重新生成一次該模型，當時的數據庫表有好幾百個，一次生成過程便需要幾十分鍾（后來EF4.1推出的code first相信便是吸取了這個教訓），二便是linq To Database的 查詢中居然不支持like模糊查詢，（委實不知道微軟的EF開發小組當時是怎么想的，后來在EF4.0才添加了這個功能），由於不支持模糊查詢，在必須要模糊查詢的地方不得已又用回sql，這代碼寫得讓人非常尷尬，惡心。當EF升級到4.1時，雖然修正上述毛病，去年 Oracle也終於推出了自己的EF for Oracle 的Provider beta版，但可惜的是至今oracle 的provider依然還沒能支持 fode first。當然還有一些后來在4.0改進了的地方，比如支持poco等。
NH在支持多數據庫方面比EF好多了，但可惜那一大堆xml配置文件更讓人崩潰，為了不用配置那一堆xml文件，找到了NH的擴展項目，NHibernate mapping attributes,然后又發現NH以及擴展項目的版本繁多，同時還有一大推相關的dll 什么common logging，log4net，總的來說就是，版本以及擴展項目較多，但文檔缺乏，使用復雜，與主干NH配合使用並非是無縫連接，相對於微軟的EF來說，畢竟不是商業化軟件，在易用性方面差很多，更多的感覺是為了玩技術而編寫出來的，沒有一定的技術水平都不好掌握。以mapping attributes來說，在實體定義的特性上標注了有關數據庫表的信息以后，還需要再寫幾行代碼把這些實體序列化為流的形式提供給NH， 再如實體的定義來說，class的特性就一大堆，什么對應的數據庫表名，實體的類的全名，實體的Type，實在太啰嗦了。
我認為這兩個框架共同的不足是都沒有使用泛型去對所有實體的CRUD作一個封裝，以EF為例，生成的實體模型里提供一大堆AddToxxx方法，微軟自己是泛型的締造者，居然不提供一個 T AddTo<T>(T t),NH還好點，它的貢獻子項目里后來有了使用泛型的封裝。
當然我批評這兩個框架的不足之處並不等於我否認其偉大之處，EF的偉大之處在於配合Linq To DB，NH聽說支持linq，雖然可能不及微軟的強大，但是起碼支持多數據庫，運行版本低（framework2.0，無須像EF那樣要裝個framework 3.5或者4.0），又不像EF偏食和挑剔，兩者的共同突出優點我覺認為是對主從（多）表關聯的支持，在網上也看過不少網友自己公布的ORM，但大多數都只是支持單表操作，說實話，那些對單表的CRUD，沒有什么技術難度。但凡事有利必有弊，EF和NH對多表查詢的支持力度大，也造成了使用的復雜性，比如NH的需要在xml中的實體配置中定義，比如EF必須要在數據庫中定義表的外鍵關聯，使用時還有延遲加載，即時加載，當處於遠程化環境下也無法使用，提交時候是否需要事務處理等諸多復雜問題。
綜上所述，我產生了要實現自己的ORM的想法，目標是簡單、易用、夠用。不是要建造重復的輪子，而是要建造適合自己的輪子。