早前分享過，當時沒有把代碼上傳到Github，只是通過郵件的形式分享給了部分需要的朋友，最近終于有時間簡單整理一下直接上傳到 Github。

目前上傳的最新版本有一些新功能特性，還有一些細節(jié)調整有興趣的自己看一下代碼。

代碼的核心實現(xiàn)簡單粗暴，我奉行夠用就好，解決問題就好的思路，不會在最初的版本中就考慮上千萬上億數(shù)據(jù)balabala之類的問題，但是如果我在工作中遇到了這樣的場景，我會去升級它并解決這樣的問題。

這個組件是我前兩年寫的，可能和現(xiàn)在流行的 dapper 有一些類似，當時我并不知道有 dapper，如果知道的話可能我就直接使用 dapper了。我寫  sheng.ADO.NET.Plus 并不是閑的無聊要造個輪子玩，而是我在自己的項目開發(fā)中，切實遇到了一些問題需要解決：使用EF帶來的不便和直接使用ADO.NET帶來的不便，我需要一個介于兩者之間的，高度自由的組件。

=====

 

目前我們所接觸到的許多項目開發(fā)，大多數(shù)都應用了 ORM 技術來實現(xiàn)與數(shù)據(jù)庫的交互，ORM 雖然有諸多好處，但是在實際工作中，特別是在大型項目開發(fā)中，容易發(fā)現(xiàn) ORM 存在一些缺點，在復雜場景下，反而容易大大增加開發(fā)的復雜度及犧牲靈活度。使用 ORM 不寫 SQL 而使數(shù)據(jù)庫交互變得簡單易行，是否能夠達到預期效果，要畫一個問號。

主要問題可能存在于以下幾點：

1.大幅度犧牲性能，這里的性能問題不是指什么單表寫入100萬次的性能對比，而是指基于如EF這樣的框架開發(fā)的項目的整體開發(fā)模式和特點造成的性能低下。

2.雖然隱藏了數(shù)據(jù)層面的設計，但并沒有從根本上降低數(shù)據(jù)訪問復雜度，只是將復雜緯度從一個點（SQL，存儲過程）轉移到另一個點（代碼），以EF為例，最終生成的代碼性能與C#書寫有很大關系，且難以通過成熟的數(shù)據(jù)庫技術反查性能瓶頸。

3.對于復雜查詢，ORM 力不從心，雖然從技術角度說實現(xiàn)肯定都能實現(xiàn)，但是代價是不值的。

 

有朋友認為 ORM 可以使不懂數(shù)據(jù)庫的開發(fā)人員也能在開發(fā)中輕松實現(xiàn)與數(shù)據(jù)庫的交互，但是，在大型項目中，讓不懂數(shù)據(jù)庫的開發(fā)人員做這塊工作，Are you kidding me?

 

在我自己的項目開發(fā)經(jīng)驗中，ORM 還存在以下問題：

1.對于大型項目的開發(fā)，表示數(shù)據(jù)的實體類和數(shù)據(jù)庫層面的持久化設計并非一一對應的關系，使用ORM根據(jù)數(shù)據(jù)庫表