早前分享过，当时没有把代码上传到Github，只是通过邮件的形式分享给了部分需要的朋友，最近终于有时间简单整理一下直接上传到 Github。
目前上传的最新版本有一些新功能特性，还有一些细节调整有兴趣的自己看一下代码。
代码的核心实现简单粗暴，我奉行够用就好，解决问题就好的思路，不会在最初的版本中就考虑上千万上亿数据balabala之类的问题，但是如果我在工作中遇到了这样的场景，我会去升级它并解决这样的问题。
这个组件是我前两年写的，可能和现在流行的 dapper 有一些类似，当时我并不知道有 dapper，如果知道的话可能我就直接使用 dapper了。我写 sheng.ADO.NET.Plus 并不是闲的无聊要造个轮子玩，而是我在自己的项目开发中，切实遇到了一些问题需要解决：使用EF带来的不便和直接使用ADO.NET带来的不便，我需要一个介于两者之间的，高度自由的组件。
=====
目前我们所接触到的许多项目开发，大多数都应用了 ORM 技术来实现与数据库的交互，ORM 虽然有诸多好处，但是在实际工作中，特别是在大型项目开发中，容易发现 ORM 存在一些缺点，在复杂场景下，反而容易大大增加开发的复杂度及牺牲灵活度。使用 ORM 不写 SQL 而使数据库交互变得简单易行，是否能够达到预期效果，要画一个问号。
主要问题可能存在于以下几点：
1.大幅度牺牲性能，这里的性能问题不是指什么单表写入100万次的性能对比，而是指基于如EF这样的框架开发的项目的整体开发模式和特点造成的性能低下。
2.虽然隐藏了数据层面的设计，但并没有从根本上降低数据访问复杂度，只是将复杂纬度从一个点（SQL，存储过程）转移到另一个点（代码），以EF为例，最终生成的代码性能与C#书写有很大关系，且难以通过成熟的数据库技术反查性能瓶颈。
3.对于复杂查询，ORM 力不从心，虽然从技术角度说实现肯定都能实现，但是代价是不值的。
有朋友认为 ORM 可以使不懂数据库的开发人员也能在开发中轻松实现与数据库的交互，但是，在大型项目中，让不懂数据库的开发人员做这块工作，Are you kidding me?
在我自己的项目开发经验中，ORM 还存在以下问题：
1.对于大型项目的开发，表示数据的实体类和数据库层面的持久化设计并非一一对应的关系，使用ORM根据数据库表
延伸阅读
学习是年轻人改变自己的最好方式