今天我想分享一下我自己的ORM框架，虽然谈不是很好，但我个人认为还是蛮好用的，跟大家分享交流一下。

首先说说我对现在主流的ORM框架的一些看法：

优点：

1. 让程序员不再关注数据库细节，专心在业务逻辑上，程序员可以不懂数据库就可以开发系统。
2. 让数据库迁移变的非常方便，如果系统需要更改使用的数据库，直接改配制就好了，不要再管不同数据库之间的语法差异。
3. 省时，可快速开发，因为不需要自己写复杂的SQL语句，不需要封装复杂的数据底层，这样可以节省很多时间。

缺点：

1. 我觉得不懂数据库的程序员不是好程序员，ORM不能帮你生成所有的业务语句，有些复杂的生成不了，还是需要写SQL，例如复杂的报表。
2. 配制过于繁琐，出错后不好定位问题点在哪。
3. 性能低，因为它内部是使用了大量反射，还有数据库检测，造成性能必然低下。
4. 需要额外的学习成本，虽然不需要学习数据库，但是需要学习ORM语句。
5. 容易引起不规范开发，因为ORM可以在任何地方写ORM语句然后调用开发，这样对于初始程序员来说他们很可能在系统的任何地方乱丢ORM语句，这样给维护带来了很大的难度。

因为我一直都不看好这些ORM框架所以缺点写多了点，可能还有些优点是我不知道的，路过的人要是知道可以给我留言，我再补上。

那现在来谈一下我自己的ORM框架，之所以称它为ORM框架是因为，它也达到了上面ORM框架的几个优点。

首先我基于抽像数据操作层，写了一套基于ADO.NET的抽像操作数据库的方法DbHelper

然后基于这个DbHelper 我开发了抽象数据操作引擎，并扩展了不同的数据库支持 这里只显示了mysql的，还有MSSQL,ACCESS其实所有支持ADO.NET的数据库都可以扩展进来

这样做了以后，我的框架就可以做到数据库无关性了，我可以使用任何数据库，甚至可以混达数据库。

现在我再说说怎么快速开发和让程序员不用关注SQL语句。

对于程序员来说，没有比看代码更直接的了，我先给大家看看代码：

这里演示了 增删改查方法，首先这里我没有写一句SQL，也没有ORM语句，写法上应该比较直观，我们数据模型进行了扩展，给字段都加入了属性。

如果我要设置一个字段的值，我就会把它的IsValue设置为真，如果我要查询一个字段我就把它的IsColume设置为真，我个人理解这种方式更接近OOP思想，更直接更容易理解，至少我现在带新人让他们用这个能很快上手，几乎没压力。

这样也避免了初级程序员随便写SQL语句，同时也方便维护和管理，又能快速开发，最主要是性能很高，因为我没用反射，也不需要ORM语句到SQL语句的翻译，同时也可以定制只查询出部分字段（现在好像一些ORM达不到这个效果）。

那有人可能会说 你的实体模型肯定很复杂，要写这个肯定很费时间，其实这句话对了一半，因为实体模型确实变复杂了，但并不费时间，因为我在上一篇博客中有提到过，我的实体模型全都是自动生成出来的，根本不需要人工来操作，包括我的数据层的代码，它确实很大很复杂，但不需要人工处理，一步生成出来就直接可以用了。

好了，今天就介绍到这里了，我的框架的具体细节后续我会慢慢的详细介绍出来，有兴趣的可以看看。同时欢迎大家对我的框架提出宝贵的意见。

我的开发框架之ORM框架