前言：

随着CYQ.Data 开始回归免费使用之后，发现用户的情绪越来越激动，为了保持这持续的激动性，让我有了开源的念头。

同时，由于框架经过这5-6年来的不断演进，以前发的早期教程已经太落后了，包括使用方式，及相关介绍，都容易引人误解。

为此，我打算重新写个系列来介绍最新的版本，让大伙从传统的ORM编程过渡到自动化框架型思维编程（自已造的词）。

于是：这个新系列的名称就叫：CYQ.Data 从入门到放弃ORM系列

什么是：CYQ.Data

1：它是一个ORM框架。

2：它是一个数据层组件。

3：它是一个工具集类库。

下面看一张图：

从上面的图可以看出，它已不仅仅是一个ORM，还附带一些带用功能。

因此：

写日志：你不再需要：Log4net.dll

操作Json：你不再需要newtonjson.dll

分布式缓存：你不再需要Memcached.ClientLibrary.dll

目前框架只有340K，后续版本将没有混淆工作，体积将更小一些。

传统ORM的发展过程：

看一张千篇一律的发展趋势图：

在开源中国里搜.NET系的：ORM，数量有110左右，在CodeProject里搜.NET系的：ORM，数量有530左右。

经过大量的查看，很容易就发现，市场上的ORM都几乎一样，唯一不同的：

就是在自定义查询语法，每家都在玩自己的花样，而且必须玩的与众不同，不然大伙都一个样，显示不出优越感。

同时这种各式各样无厘头的查询语法糖，也浪费了不少开发人员的时间，因为学习的成本是要看一本书或一个从入门到精通系列。

综合看来，能跳出这个趋势的，木有！说明造ORM是有套路的，创新，是需要艺术细胞的。

曾经，我也有一个很简单又传统的ORM叫XQData：

是我2009年时造的，发现现在还躺在硬盘里，任性地就开源分享给各位还没造过ORM的小伙伴们当入门指南用了。

XQData源码（SVN下载）地址：

CYQ.Data 的自动化框架思维：

在早期的CYQ.Data版本里（具体多早不好说），和传统实体型ORM比起来，除了不拘一格，看起来有点潮，值的鼓励和关注之外，用起来的确没感觉爽在哪。

随着自动化框架思维的形成，经过多年的完善，如今，和实体型ORM的差距已经不在同一个层次上了。

先看实体型ORM的代码编写方式：实体继承自CYQ.Data.Orm.OrmBase

using (Users u = new Users()) { u.Name = ; u.TypeID = Request["typeid"]; //.... u.Insert(); }

看起来很简洁是不？的确是，只是它太固定化了，不够智能，一经写死，就是天造地设耦合的一对。

为什么我都推荐用MAction？因为它有自动化框架思维：

看以下代码：

using (MAction action = new MAction(TableNames.Users)) { action.Insert(true);//这中间是没有单个赋值过程的 }

相比较一下代码就可以看出优势来了：

1：代码少了，没了中间的赋值过程；

2：和属性和数据库字段无依赖了：不管你前端修改界面，还是修改数据库，后台代码都不作调整；

如果增加切换表操作和事务，这时候优势又多了两个：

1：实体ORM：只能用分布式事务包含代码段，不能复用链接。

2：MAction：可以用本地事务，可以复用链接。

上面的MAction代码，还有一个TableNames.Users表名依赖，如果把它变成参数，你就会发现不一样的天空：

using (MAction action = new MAction(参数表名)) { action.Insert(true); }

就这么两行代码，你发现完全和数据库和界面解耦了。

到这里你就发现，这就是这款框架和实体型ORM不在一个Level的地方：

1：因为它实现了数据层和UI层真正意义上的解耦。

2：因为它是基于自动化框架编程的思维的，不再有一个一个属性赋值的过程。

看到这里，再回看ASP.NET Aries 开源框架里的AjaxBase，就能理解为啥后台总那么点代码，能处理自动处理任意表和数据了：

下面的方法只需要前端页面只需要传递一个表名（+对应的数据）：

如果进一步，把表名配置在数据库里的Url菜单字段，那么就形成一个自动化的页面了：

而这些自动自动化框架编程思维，都是实体ORM不具备的，实体ORM只能小打小闹的针对某个界面一堆代码一堆代码的敲。

看一个API接口设计：

假设，有个App项目，有Android版和IOS，它们都需要调用后台API，这时候，你怎么设计？

先不动，等着App产品经理把界面原型都定稿了，再针对App的界面需要哪些元素，和开发App开发工程师商量一下，再针对请求写方法？

毕竟你要知道读哪个表，查哪些数据，所以你只能被动？每新增一个页面或功能，你都要跑去后台写一堆业务逻辑代码，然后又进行联调？

是不是特累？

看一下直接用此框架后，你的设计的过程会变的怎么简单、优雅和具有抽象思维：

接口核心代码：

using (MAction action = new MAction(tableName)) { action.Select(pageIndex, pageSize,where).ToJson(); }

接下来你要设计的是：

1：给App定好客户端请求参数的格式：｛key:'xx',pageindex:1,pagesize:10,wherekey:'xxxx'｝

2：将表名映射放到数据库（Key，Value），App只传递Key当请求名称

3：根据实际业务，构造好where条件。

多设计几个这样通用接口，给到app开发人员就可以了，看看有什么优势：

1：可以减少很多沟通成本。

2：API的设计是通用型的，减少大量的代码，后续维护简单可配置。

3：一开始就可以动工了，不需要等到App原型启动后再动手。

4：连表是否存在，长成什么样，都可以事先不管用，后期可数据库配置。

5：实现一套之后，换公司换项目换业务也可以用，因为你的设计与具体业务是解耦的。

试想换成实体ORM，你是不是要事先有数据库，生成一堆实体吧，然后具体业务不断New实例吧，思维的局限就只能被限制在具体的业务。

框架的抽象思维及where条件的智能化推导

先看一张图：