CYQ.Data 数据层框架

CYQ.Data 是一款由路过秋天创作的支持多数据库应用[Txt,Xml,Access,MSSQL,Oracle,SQLite,MySql]的底层数据库操作类库,使用本类库可以轻松快速开发项目(QQ群:6033006)。

CYQ.Data 数据框架 实现数据的按需更新的改进

框架原理 | | | 发表日期 :2011/4/3 1:50:50#楼主  

首先感谢dudu发了这么一篇:博客园现代化建设—准备用Entity Framework实现数据的按需更新

在帖子的第十六楼,我留下了这样的留言:

路过秋天:
这是一个复杂又冲突的设计问题:
1:为了按需要更新,你必不可免的需要有一份数据在内在的。
正如说没有缓存时,你需要多进行一次查询,无论是单个的查询,还是多更新几个字段,这个的性能点达到你需要这样处理的程度?
2:好,假设有已有缓存还没过期,你可以减少一次的查询,得到内在的实例的数据来进行比较,通过比较来更改isChanged标识,然后感觉得到了很大的提升,但这存在的是什么问题?
3:在第2步时,你需要这样处理的前提,是知道它是准备执行Update操作,所以你需要这样处理,如果是Insert呢?你提交的数据将有很多字段失踪了。
4:于是,这种方式,只能针对已知的某个页面,它不在被整体的泛用,再于是,产生的性能点并不可观。
5:最后,还是从客户端进行判断来提交相应的数据方式来得适合一些。


解决方案总在问题产生,分析,思索之后产生。
正如我引用内容所分析的问题一样,要从整体上考虑,就必须处理Insert的情况。

在经过前面几步的分析后,思索了一下,最终得出一个简单更优的解决方案,与大伙共享:

一:CYQ.Dtata 数据框架目前的设计方式:

1:在框架的内部的最小值赋单元里,有个bool型的IsChanged字段,来标识一个字段的值是否被改变过。

2:框架在组合SQL语句时,再根据此标识来组装相应的SQL语句。

从上面的两点看出,此设计基本上能实现按需要更新或按需要插入功能。

我们再看一下实际的应用场景:

场景一:看似完美的解决了按需更新或插入

using(MAction action=new MAction(TableNames.Blog_Users))

{

                 action.Set(Users.ID,1);

                  action.Set(Users.UserName,"cyq1162");

                  ation.Update();

}

说明:

OK,由于在值赋时会改变IsChanged标识位,于是无论是组Insert或是组Update,都会实现按需更新或插入。

场景二:问题出现了

比如一个博客后台,总会有很多选项或提交更新的地方:

using(MAction action=new MAction(TableNames.Blog_Users))

{

                  action.Set(Users.ID,1);

                  action.Set(Users.UserName,"cyq1162");//一般不会改用户名,这仅是示例

                  action.Set(Users.Nickname,"路过秋天");//修改昵称

                  acton.SetAutoPre("txt","ddl");//通过自动取值方式,省点代码,不然得写十多行赋值语句

                  ation.Update(true);//启用自动取值方式

}

说明:

在此情况下,所有Set的代码都会被更新,因为全都有了赋值动作了,事实上我们仅改了个别文本框的值。

假如:

我们就在设置IsChanged时,加个判断,值和以前一样,就不改变?

如此看似能解决,但又一问题又产生了,看下一场景。

场景三:按场景二的方式改进,Insert将有可能产生问题

假设我们有以下类似的应用场景:

using(MAction action=new MAction(TableNames.Blog_Users))

{

                  action.Fill(id);//查询填充一条数据,于是行或实体全有了数据。

                 // ...然后取值处理一些事情,然后进行一些判断......然后我们需要再添加一行新数据,再new一个新行或实体?可偏偏有时你会希望一个对象能多用几次,省点资源,于是有了以下操作

                  action.Set(Users.UserName,"新用户名");//重新赋值,

                  action.Set(Users.Nickname,"刚好这昵称有人用了");//再重新赋值

                  ation.Insert();//插入数据,于是当然期望新添加行的数据只有包括这两个重新赋值的数据。

}

分析:

OK,由于框架原先的设计,只会对赋值的语句组装SQL语句,所以我们并不担心原来的数据会产生什么影响,只要重新赋值,就可以添加新数据了。

如果:

在场景二的时候,我们加了判断,不改变IsChanged标识位了,会产生什么影响?

产生问题:NickName没有被插入,原因是因为行里本身有数据,相同值的赋值不再更改标识位的。

在一瞬间的意识流分析到以上问题后,所以有了在dudu文章下面的留言。

当然应用场景是有可能相似的,只是实现的代码或者另有不同。

二:CYQ.Data 数据框架的改进设计

在分析后问题的产生,意识流又有了一些许冲动,来了不少灵感,于是有了以下的改进方案

1:单纯的bool型的IsChanged无法适应这种情况,那增加更多的标识类型呢?

2:于是进而转之再有了新想法:将bool型的IsChanged更改为int型的State。

于是,多了可扩展的N种状态:

0:状态未被更改;1:产生赋值动作,值相同;2:产生赋值动作,值不同。

于是,问题明朗化并得到解决:

1:产生Insert语句时,判断State>0即可

2:产生Update语句时,判断State>1即可。

3:赋值时,同样将新旧值进行判断,更改State为1或2。

至此,框架改动起来不过3分钟不到,但却完成了一项不小的功能改进。



新浪微博粉丝精灵,刷粉丝、刷评论、刷转发、企业商家微博营销必备工具"
游客[注册][116.54.28.*]2011/8/21 1:19:58#1
方向错误,就什么都没意义了。

持久层不该去维护对象的属性状态,并对其负责。
只有一个例子,那就是 DataSet 系列——原因是其用于 MVC 作为通用的 Model 容器,在 View 中使用时用来记录状态变更。

而它是与具体的业务无关的——或者说 DataSet 的“业务”就是要解决这个问题的。但ORM生成的代码和ORM自己要去解决这个问题还不如只需要提供机制让业务层能够知道实体的属性值发生了变化,至于之后怎么处理,由业务层来决定(再根据决定是否调用持久层完成数据存取动作),这样才是合理的方式。

所以说,设计思想比技术实现能力更重要。先考虑设计是否合理、是否还有更合理的方案?
回复这个框架的场景的出现,首先,它不是一个纯ORM,虽然有扩展ORM功能。
有一种设计,是基于理论,职责,去设计。
也有一种设计,是基于简单,实用,去实现。
所以没有什么方向错不错。
正如不能拿mvc来说webform不够mvc就说webform不对。

发表评论

论坛公告

    数据框架 CYQ.Data QQ群:6033006
    使用本框架进行开发,入门简单,开发效率高,性能优越,更有详尽的API文档,有相关的使用帮助文章、示例文章、更甚有相关的视频教程及辅助工具。 关键还是免费与开源,实在是居家旅行、项目开发、学习研究的必备良品!!!!!!


    在线帮助:欢迎联系

帖子搜索