MVVMLight怎么与三层结构结合？

[wangbinykit]

感觉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");会冲突吗

[lhx527099095]

NotifyPropertyChanged("ID");

这个应该是在viewmodel里面写的


实际上我的理解是这样的

三层或者说多层设计中 mvvm是ui层得扩充
这就好比三层架构和mvc不冲突一样 mvc主要是ui层东西

所以说 整体上架构应该是这样的
ui（MVVM vm层是处理ui逻辑的）
bll（业务逻辑）
dal（数据）

不知道有帮助没有对你 呵呵
而且我觉得不要为了mvvm而mvvm 主要了解应用的场合 和目的 这样才能用好
不然框架只能给你带来负担
比如我们在开发很多图形操作 互动性很强的界面的时候 用mvvm是找死
各种鼠标事件 很复杂 好比 你用mvvm开发游戏 多费劲啊

所以 具体情况 楼主自己多琢磨琢磨 和同事讨论下吧

[在路上20130607]

NotifyPropertyChanged("ID") 是当前对象的 id 不会互相影响

[wangbinykit]

周围就自己弄sl。没人能讨论。我好像过于纠结了

[以专业开发人员为伍]

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);
myTextBlock1.SetValue(水泵Property, obj);
myStoryBoard1.SetValue(水泵Property, obj);

这就可以将数据注入给三个控件了。它其实是将实体跟ui控件进行“轻快地”关联。

[以专业开发人员为伍]

你可以看到“水泵Property”定义时是可以在Register(......)这个语句中设置触发器的，因此当数据关联到一个控件时可以执行触发器，你可以进一步定义数据跟所注入的控件之间的交互行为。



而传统的“三层”是指一个网络架构，是“客户端-应用服务器-数据库服务器”架构概念。而ui编程是讲求高效、进程内处理的架构，跟“三层”其实并不是客户随便硬性套用（虽然貌似在名词儿上都是有“三”这个数字出现）。

而mvc原本是40年前的最原始的交互式图形ui领域最初级、最基本的概念。只不过是前些年被struts再次炒作并胡乱用来说明那种网页编程模式，已经脱离了原来的mvc的概念。asp.net mvc更是拾人牙慧地去抄袭java中的概念。这些所谓的mvc，你搞懂它说不定会害了你，因为它受限于2000年初那时的web编程技术水平（而不是ajax技术水平），所以它的流程和概念是臃肿的、蹩脚的。

silverlight的mvvm更像是winform，你了解mvvm时不需要去过分纠结于什么mvc概念。

[javamy023]

帮顶一下，待大牛来解