前言：
随着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下载）地址：http://code.taobao.org/svn/cyqopen/trunk/XQData
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条件的智能化推导
先看一张图：
对于表的常见数据增删改查操作，从上图可见，框架最终抽象出两个核心参数：
表名+where条件：
曾经我也曾思考过语法糖，是否把Where这一块设计成：.Select(...).Where(...).Having(...).GroupBy(...).OrderBy(...)...
后来还是坚持初心保持原生：
1：开发人员没有学习成本。
2：保持框架的青春创造力。
3：具备自动化框架思维。
语法糖的坏处：
1：框架自身复设计杂度增加。
2：使用者学习成本高，使用复杂度增加。
3：不适合自动化扩展：设计已成表达式，无法动态根据某Key和表去动态构造查询条件！只适合具体实例和业务，不适合自动化编程。
当然，在大多数的Where条件里，很多是根据主键或唯一键件的条件，为了进一步抽象及适应自动化编程，我设计出了自能化推导机制。
针对where的智能化推导：
看以下两个代码：左边是构造相对完整的的where，右边的能自动推导出where。（内部有防SQL注入，所以不用担心where条件注入问题）。
通过智能化推导，去掉了主键名参数（因为不同的表的主键表不一样），智能推导产生，可以让编程者主要关心传过来的值，而不用关注具体的主键名叫什么。
如果值的是是“1,2,3"这种按逗号分隔的多值，框架会自动推导转成 主键 in (1,2,3) 条件。
再看两组代码：左边依旧是相对完成where条件，右边是智能推导型编程。
注意：同样是传值，但我们要的是UserName，不是主键，系统也能推导出来？
这时候系统会根据值的类型、主键、唯一键等值的类型综合分析，得到该值应该用主键或是唯一键去构造出where。
（PS：唯一键推导是昨天才完成的功能，所以只有最新版本才有。）
正因框架有智能推导功能，屏蔽字段差异，让使用者只需要关注传值即可。它也是让你实现自动化框架编程思维的重要功能。
自动化批量式编程：
看一张图：MDataTable：它能和各种数据类型直接产生批量式互相转换：
MDataTable 是框架的核心之一，上篇文章就有对它的专属介绍。
当然，Table的构建，往往基于行，所以再看一张图：MDataRow （它是单行数据的核心）
其实正因为MDataRow打通了单行的数据的批量来来去去，所以才造就了MDataTable的多行数据的批量处理。
事实上MDataRow是核心实现层，只是它比较低调。
补充重要地址：
1：源码SVN地址：https://github.com/cyq1162/cyqdata.git
2：项目Demo示例SVN地址：http://code.taobao.org/svn/cyqopen/trunk/CYQ.Data.GettingStarted/
3：框架下载地址：
1：VS高版本：Nuget上搜cyqdata
2：VS低版本：http://www.cyqdata.com/download/article-detail-426
总结：
在使用框架编程时，你会发现更多关心的是：数据的流向、及如何为抽象的参数构建配置系统。
在大部分的编程时间里，除了特定的字段意义需要具体关注，多数都是基于自动化编程思维，数据流向思维。
早期的系列：没有这种编程思维，难免看了介绍后会有种违各感。
而今的系统：自动化框架编程思维，也是用户忠诚度高喜欢上的原因，特别是免费之后。
当然，后续也会针对此系列，重新写使用教程，并且教程源码也会同步更新到SVN，敬请期待。