model层到底有没有意义

动手写了一点小程序
类似于petshop4.0

在写DAL层时，比如一个更新字段
update   table   set   userid   =   @userid
假如客户端需要将userid   列更名为col_userid

我依然需要改DAL层和model两个层

假如数据库要适移至oracle或db2，退一步access

我的dal层几乎需要重写，因为我不可能写成完全样的通用的程序，毕竟我还要用各个数据库的一些优点，不可能不用proc

model存在的理由到底是什么？如何让它有存在的最大理由？难道仅仅是为了面向对象而封装？
这个问题让我比较郁闷。

还请有经验的朋友给讲讲，谢谢了。。

------解决方案--------------------
根据实际需求 不过学习一下也是不错的
------解决方案--------------------
学习就好了.
------解决方案--------------------
毕竟像你这样经常更换数据库，更换列表名的比较少..
仅当学习用了
模板是死的，人是活的嘛，哈
------解决方案--------------------
期待
------解决方案--------------------
请搜索petshop codesmith 模板
------解决方案--------------------
当然有意义，像在有些大型应用，三层架构就用得上了，比如说：
有一个产品，它以前是用SQLServer数据库支撑的，现在要转到Orcle下面来，会怎么样呢？

如果产品是不分层的，那么那么我们要把混杂在业务代码中的数据库操作语言一一找出来并改正。想想这样的情开形将会是怎么样的？我想会很痛苦。因为你不得不查看大部分代码。

那么如果这个产品的数据层独立出来了会怎么样呢？你只需要重写数据层的代码而已，业务层的代码你可以不去管它，工作量会少很多。而且代码也更易于维护。

当然，并不是任何情况下都要这样做，有些应用使用了三层架构会使事情变的更复杂。
所以什么时候该用三层什么时候不该用三层要看项目的具体情况去决定。而不要一味的去追求所谓的新的技术或概念。

要记住，解决问题最好的方法就是那个最简单的方法，而不是那个最先进的方法。

PS:Petshop本来是不该用三层架构，MS做这个项目只是在告诉我们，.NET也可以这样做。
------解决方案--------------------
移植性提高
------解决方案--------------------
学习一下
------解决方案--------------------
model 本来就是为了 更好的 适用 表的变化
而不影响 程序.的其他结构.
------解决方案--------------------
我也遇到过楼主的这种情况，遇到这样我就又建立一个Model文件，这样不大方便的，有没有更好的办法解决这个问题呢 ？
------解决方案--------------------
对于大型而复杂的项目，业务逻辑是大头
如果你的项目只是访问数据库而已，没有什么业务逻辑
可以只有dal层
------解决方案--------------------
Model就是提供对实体的OO方式的操作，隔离数据库与DAL
------解决方案--------------------
存在就是合理的。楼主看看PETSHOP就会明白，用MODEL是很有必要的
------解决方案--------------------
DAL的变化是和Model没有关系的
Petshop
就是很好的例子
sql 和 oracel的切换 只是加载DAL实体不同而已
表结构没有变化model也是不变的
即便表结构变了model的修改也不会 影响其他部分.