感觉mvvm中的model与三层中的model；mvvm中的viewmodel与三层结构中的BLL 是一致的
有没有相互结合的例子。
顺便问个问题：
mvvm中的model中对于数据库表的每个字段都有类似：
private int _id;
public int ID
{
get{ return _id; }
set{ _id = value;
NotifyPropertyChanged("ID");
}
}
一张表对应一个model；每个表里都有ID字段；那么这些 NotifyPropertyChanged("ID");会冲突吗
------解决方案--------------------------------------------------------
NotifyPropertyChanged("ID") 是当前对象的 id 不会互相影响
------解决方案--------------------------------------------------------
NotifyPropertyChanged("ID");
这个应该是在viewmodel里面写的
实际上我的理解是这样的
三层或者说多层设计中 mvvm是ui层得扩充
这就好比三层架构和mvc不冲突一样 mvc主要是ui层东西
所以说 整体上架构应该是这样的
ui（MVVM vm层是处理ui逻辑的）
bll（业务逻辑）
dal（数据）
不知道有帮助没有对你 呵呵
而且我觉得不要为了mvvm而mvvm 主要了解应用的场合 和目的 这样才能用好
不然框架只能给你带来负担
比如我们在开发很多图形操作 互动性很强的界面的时候 用mvvm是找死
各种鼠标事件 很复杂 好比 你用mvvm开发游戏 多费劲啊
所以 具体情况 楼主自己多琢磨琢磨 和同事讨论下吧
------解决方案--------------------------------------------------------
ui端开发模式跟“三层”没有关系。ui端开发就是ui端开发，不要过度联想，否则自己纠结。
如果想了解viewmodel，那么应该多使用DependencyProperty来了解这个概念。这其实就是向ui控件中“注入”数据对象信息。我们完全不用去管什么（由struts概念的）mvc。
------解决方案--------------------------------------------------------
由struts所带来的那种又臃肿又慢的、基于服务器端一遍遍刷新html的所谓mvc方法，可以说是一种“100年前的中国老太太的裹脚布”式的所谓ui概念。它其实是将实体跟ui控件进行“痛苦地”关联。
而对于silverlight这样的富客户端应用程序来说，比如说你有一个“水泵”数据对象实体，而界面上有7、8个子控件（甚至例如说一个StoryBoard）都想关联它，你可以定义一个
public DependencyProperty 水泵Propety= DependencyProperty.Register("水泵", ......);然后分别执行
myUserControl1.SetValue(水泵Property, obj);这就可以将数据注入给三个控件了。它其实是将实体跟ui控件进行“轻快地”关联。
myTextBlock1.SetValue(水泵Property, obj);
myStoryBoard1.SetValue(水泵Property, obj);