对于表的常见数据增删改查操作，从上图可见，框架最终抽象出两个核心参数： 表名+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是核心实现层，只是它比较低调。

总结：

 在使用框架编程时，你会发现更多关心的是：数据的流向、及如何为抽象的参数构建配置系统。

 在大部分的编程时间里，除了特定的字段意义需要具体关注，多数都是基于自动化编程思维，数据流向思维。

 早期的系列：没有这种编程思维，难免看了介绍后会有种违各感。

 而今的系统：自动化框架编程思维，也是用户忠诚度高喜欢上的原因，特别是免费之后。

 当然，后续也会针对此系列，重新写使用教程，并且教程源码也会同步更新到SVN，敬请期待。