框架设计：实现数据的按需更新与插入的改进

首先感谢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分钟不到，但却完成了一项不小的功能改进。

 

由于突然间断网，延迟了一个多小时发布了。