你的位置:首页 > ASP.net教程

[ASP.net教程]CYQ.Data 从入门到放弃ORM系列:开篇:自动化框架编程思维


前言:

随着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是核心实现层,只是它比较低调。

总结:

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

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

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

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

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