cyq.data 连接mysql_CYQ.Data 轻量数据层之路 框架如何应对数据库变化

内容：

请问大家是如何处理以下问题：

Model是数据库表的实体映射，当系统的需求出现新的变换，例如增加新的功能时数据库需要增加新的字段，

或需要去掉和更换某些旧的功能，那么对应的数据库字段肯定是会修改的。如果数据库的表结构有变换，

对应实体Model层肯定有变换。

改一个字段，

Model层必须要修改，

那么DAL层必须要修改，

SQL语句必须要修改，

表示层的数据展现也是依赖Model层的属性名称，也要修改。

这不符合设计模式的单一职责。牵一发动全身。

并且这样设计，那用啥设计模式都是白搭。

其次工作量非常大，例如商品表的话 光执行查询的地方就不得了。

请问大家是如何处理这种问题，或者怎么把影响降到最低。

帖子下面有N多跟贴讨论问题，但实质还没提出根本的解决之道，或者像有帖子里人说的：

1:楼主问题的根源在于：“Model是数据库表的实体映射”，所以由此进行的所有推导都是错的

2:需求变更后修改的是模型，不是数据库！

3:开一贴专门批判一下“数据库驱动思维”

当然，原贴留言还请看原贴才真实。

下面进行本篇说明：

本篇不对理论性的东西进行相关讨论或解释，只想对针这句“怎么把影响降到最低”，结合CYQ.Data 框架说说。

不管基于什么原因，或者是对是错，一种先数据库，再实体的方式，已被多数人所接受，并以此方式一直进行着相关的开发。

CYQ.Data框架如何应对变化：是“怎样把影响降到最低”的

应对一：枚举与实体类的引入

对于CYQ.Data 框架，从本质上来说，是走弱类型的索引方式，所以，是可以不存在枚举与实体的。

不过为了方便开发，可以引入枚举与实体，对于本框架所有的相关文章，都采用引入枚举的方式，所以对于枚举就不做多介绍了。

以下说下如何引入可应对变化的实体类：

例如Users表：

public class Users

{

public static int ID = 0;

public static string UserName = "UserName";

public static int Password = 2;

public const int CreateTime = 3;

}

说明：

从这里看到，引入的实体和常见的都是属性的不一样吧，这里即可以用静态属性，还可以是常量,可以是整型，也可以是字符串。

那具体是怎么应对的？

假如：将表Users的UserName改成MyName,应对的方法当然是改一行代码就行了,其它调用方式不变：

public static string UserName = "MyName";

有人疑问：如果是把CreateTime改成LoginTime呢？你上面定义是整形哦？那你就把它换成：

public const string CreateTime = "LoginTime";

说明：

对于这种修改，即不用xml对配置，也不用修改其它模块的内容，只修改Model里的几个字就行了。

如果增加字段，一样了，那你就增加一静态成员属性了。

应对二：用AutoSetPre应对界面上增加与更新的代码

对于一个属性的添加与更新，本框架有N种方式了，这里只举例应对的一种。

如果是正常的写法，我们都会对每个属性赋值，然后才更新如：

MAction action=newMAction(TableNames.Users);

action.Set(Users.UserName,"路过秋天");

action.Update(2);

action.Close();

如果我们尽量使用AutoSetPre方式，将变化转到前台UI去，对于字段多的，你还可以省略很多代码如：

MAction action=newMAction(TableNames.Users);

action.SetAutoPrefix("txt");

action.Update(2，true);

action.Close();

说明：

对于这种方式，只要前台UI存在TextBox并设其id为txtUserName即可。

如果此时数据库UserName被修改成MyName，也只需要修改前台UI的控件名称即可,至少修改UI你不用重新编绎代码。

同样对于添加数据，你只需要：

MAction action=newMAction(TableNames.Users);

action.SetAutoPrefix("txt","ddl");

action.Insert(true);

action.Close();

剩下的事，交给UI处理了。

应对三：视图与自定义多表SQL查询

视图：MAction支持视图操作，而且和普通表操作一模一样，对于视图的变化，你只要改了数据库字段，视图会自动帮你更新，所以根本不需要处理。

自定义多表的SQL：只需要把自定义多表的SQL统一管理，或者在性能要求不高时多用select *方式，即可避免出现字段名称出现，或者出现了，由于统一管理，你可以很方便的修改并单独编绎更新，当然了，如果你把它存到或叫映射到xml，那直接修改xml即可，这也是应对方式之一了。

应对四：界面绑定

如果你的界面上采用方式的绑定，在修改完数据库字段后，你也只需要修改UI，并不用做编绎处理。

另一种方式如果采用GridView的自动生成列方式，你连UI都省了。

最后结言：

本框架在应对这种数据库变化方式，适应能力是极强的，关于具体实现方式，有相关开源代码，各位看官可以直接下源码研究了。

如果有其它疑问，请留言。