早前分享過，當(dāng)時(shí)沒有把代碼上傳到Github，只是通過郵件的形式分享給了部分需要的朋友，最近終于有時(shí)間簡單整理一下直接上傳到 Github。
目前上傳的最新版本有一些新功能特性，還有一些細(xì)節(jié)調(diào)整有興趣的自己看一下代碼。
代碼的核心實(shí)現(xiàn)簡單粗暴，我奉行夠用就好，解決問題就好的思路，不會在最初的版本中就考慮上千萬上億數(shù)據(jù)balabala之類的問題，但是如果我在工作中遇到了這樣的場景，我會去升級它并解決這樣的問題。
這個(gè)組件是我前兩年寫的，可能和現(xiàn)在流行的 dapper 有一些類似，當(dāng)時(shí)我并不知道有 dapper，如果知道的話可能我就直接使用 dapper了。我寫 sheng.ADO.NET.Plus 并不是閑的無聊要造個(gè)輪子玩，而是我在自己的項(xiàng)目開發(fā)中，切實(shí)遇到了一些問題需要解決：使用EF帶來的不便和直接使用ADO.NET帶來的不便，我需要一個(gè)介于兩者之間的，高度自由的組件。
=====
目前我們所接觸到的許多項(xiàng)目開發(fā)，大多數(shù)都應(yīng)用了 ORM 技術(shù)來實(shí)現(xiàn)與數(shù)據(jù)庫的交互，ORM 雖然有諸多好處，但是在實(shí)際工作中，特別是在大型項(xiàng)目開發(fā)中，容易發(fā)現(xiàn) ORM 存在一些缺點(diǎn)，在復(fù)雜場景下，反而容易大大增加開發(fā)的復(fù)雜度及犧牲靈活度。使用 ORM 不寫 SQL 而使數(shù)據(jù)庫交互變得簡單易行，是否能夠達(dá)到預(yù)期效果，要畫一個(gè)問號。
主要問題可能存在于以下幾點(diǎn)：
1.大幅度犧牲性能，這里的性能問題不是指什么單表寫入100萬次的性能對比，而是指基于如EF這樣的框架開發(fā)的項(xiàng)目的整體開發(fā)模式和特點(diǎn)造成的性能低下。
2.雖然隱藏了數(shù)據(jù)層面的設(shè)計(jì)，但并沒有從根本上降低數(shù)據(jù)訪問復(fù)雜度，只是將復(fù)雜緯度從一個(gè)點(diǎn)（SQL，存儲過程）轉(zhuǎn)移到另一個(gè)點(diǎn)（代碼），以EF為例，最終生成的代碼性能與C#書寫有很大關(guān)系，且難以通過成熟的數(shù)據(jù)庫技術(shù)反查性能瓶頸。
3.對于復(fù)雜查詢，ORM 力不從心，雖然從技術(shù)角度說實(shí)現(xiàn)肯定都能實(shí)現(xiàn)，但是代價(jià)是不值的。
有朋友認(rèn)為 ORM 可以使不懂?dāng)?shù)據(jù)庫的開發(fā)人員也能在開發(fā)中輕松實(shí)現(xiàn)與數(shù)據(jù)庫的交互，但是，在大型項(xiàng)目中，讓不懂?dāng)?shù)據(jù)庫的開發(fā)人員做這塊工作，Are you kidding me?
在我自己的項(xiàng)目開發(fā)經(jīng)驗(yàn)中，ORM 還存在以下問題：
1.對于大型項(xiàng)目的開發(fā)，表示數(shù)據(jù)的實(shí)體類和數(shù)據(jù)庫層面的持久化設(shè)計(jì)并非一一對應(yīng)的關(guān)系，使用ORM根據(jù)數(shù)據(jù)庫表
