数据访问层（DAL）如何应对后台数据库结构变化？
大家都用过数据访问层（DAL）吧，这么做的确是很方便，但DAL中的代码多半都是根据数据库结构自动生成的，包括强类型的数据集，所以在后台数据库结构不变的情况下，节省了很多时间。
但实际项目中肯定会有后台数据库结构反正细微变化的情况， 比如需要增加字段，或者字段类型的变化，或者字段长度变动等等，这时候可能你已经利用这个DAL写了一下表现层代码了
那么遇到这种后台数据库的变化，这个自动生成的DAL是怎么来应对这中变化的呢？
关于DAL，可以参考
http://www.asp.net/learn/dataaccess/tutorial01cs.aspx?tabid=63
中文版
http://www.cnblogs.com/lovecherry/archive/2006/07/02/440840.aspx
[解决办法]
面向对象而不要面向数据库编程
在dal层把所有的数据库字段都转换成对象的属性,换数据库修改dal就ok了
[解决办法]
不用，其出发点挺烂的。如果不限制死必须使用哪种数据库，写程序都是直接写class，然后自动产生数据库。因为class中的定义是自然的，字段类型、属性约束代码、字段之间的关联约束等等，都是从应用出发的。数据库是为设计服务的，你的设计代码是从实际需要、按照普通的oopl编程方法直接写出来的，你最初并不需要确定是否要使用关系数据库。如果你的代码是从关系数据库结构中得来的，那么得到的类型定义我敢肯定是非常低级代码。低级的代码手工修改吗？那么手工修改来增加高级功能之后，怎么可能“即使有变动再生成一次就好了”呢？你最终被捆绑在某种低级数据库的低级接口上，你会发现还不如直接对存储过程编程算了，你会觉得两层结构最可取。
自动化持久数据，根本不应该从数据库出发。应该先假设内存就是数据库，完全自由地使用oopl。其中Linq就是个好的概念。
一个写程序的完整过程如下：
using(Domain dm=new 我的数据服务( "http://www.123.com/db "))
{
驾驶员 p=new 驾驶员( "老张 ",38);
汽车 c=new 奥迪( "AD1812772 ",Red,6);
c.驾驶员=p;
dm.UpdateLevel=1;
dm.Save(c);
}
其中，dm是你打开一个数据服务，它可能是基于本地内存缓冲区、数据库文件、随即存取文本文件、WebService、c/s数据库等等都有可能。Save方法用来保存对象。保存c的时候就自动保存了p，因为p是c直接包含的一个组成部分。
不需要去设置数据库结构，我们在定义“驾驶员”和“汽车”的时候，根本不考虑数据库。跟一个初学者写代码一样，直接写class定义，假设内存中的对象永远也不过期。
dm在处理对象的时候会自己检查对象所在的Assembly的版本号，并且自动反射对象类型来更新数据库结构。最多，我们在类型上声明一下B+树，不需要更多地考虑数据存取知识。
[解决办法]
通过Assembly.CreateInstance可以根据名字创建实例，如果要动态加载dll还要用Assembly.Load或者Assembly.LoadFile可以实现反谢机制
[解决办法]
dal是增 删 改 查
影响大的是查 改
如果是codesmith的生成的话,影响不大,接着改改模版就是了
或者是用codedom维护一下自己的代码
有些东西就不太好办了,比如说动啥生成的代码
