Silverlight/MVVM设计：我的模型是什么，逻辑放在哪里？

我用叉子叉线

我对MVVM模式的理解与视图和ViewModel部分是一致的

但是模型部分呢？它是技术对象模型（EntityFramework自跟踪生成的类，然后位于web服务后面，然后在服务器中包含所有业务逻辑）还是应用程序逻辑模型（我们当然会基于实体类在Silverlight客户端上重新创建它——感谢PRISM项目链接器——它将提供面向GUI的操作，提供更多的业务逻辑，并将封装肮脏的技术内容以访问WS，从而将实体上的修改传播到数据库）

（个人，我在想第二个）

在我们的Silverlight/WCF（不是RIA）项目中，我们管理文档，它粘贴到InboxViewModel.cs，其中包含要显示的文档列表。InboxView中的ListBox数据绑定到InboxViewModel中的DocumentList ObservableCollection属性。但ListBox ItemTemplate数据绑定到DocumentViewModel.cs，后者封装了实体生成的Document.cs类

重点是这个DocumentViewModel实际上被其他视图使用…（对我来说部分是可以的，如果MVVM在视图和ViewModels之间规定了一个双射，则一点也不可以？但这不是我的观点…）

依我的拙见，我宁愿使用DocumentModel.cs而不是DocumentViewModel.cs，它可以由多个ViewModels（InboxViewModel、EditDocumentViewModel…）共享，并封装对WS的调用，以便在服务器端使用客户端修改的实体触发业务操作。 然后，我们将拥有一个应用程序逻辑模型或面向GUI的模型（M-V-VM），此外（以及下面，从层的角度来说）还有视图模型（M-V-VM）和视图（M-V-VM）。所有这些都在Silverlight一侧

但还有两个问题：

1-如果保留我的拙见，是否可以将ItemTemplate直接数据绑定到模型对象？因为没有任何视图直接绑定到DocumentModel，而是绑定到InboxViewModel（例如）中的属性，该属性是DocumentModel对象

2-更一般地说，服务器端和客户端实现的业务逻辑的一部分是什么？ 由于服务器打算向其他（虚构的未来或未来的虚构的：p）应用程序公开WS，我们真的希望将所有第一个应用程序业务逻辑都放在服务器中，还是只通过WS公开原子操作，让所有应用程序实现其正确的逻辑

我的技术负责人不断向我推荐，但他/他并没有给我任何答案，而且，我只是想在这里独立思考

谢谢你们所有人。。。

---

干杯

我想你提到的是MVVM的一些方面：A）提出的问题最多，B）达成的共识最少

该模式包含三个层：模型是数据，视图是屏幕，ViewModel位于它们之间。我开始认为这是不准确的，或者至少不是最优的。从数据到屏幕，我的目标是：

A） 服务层：此代码可以是实际的服务或围绕ADO.NET调用的包装器。无论是什么风格，它的工作都是与物理数据源交互。它使用实体（不一定是EF类，只是表示数据库的类）来实现这一点

B） 实体层：这些是由服务层获得的类。与物理数据源之间的所有通信都是通过这些实体类进行的

C） 数据模型层：这些类包装/管理实体层。具体而言，它们实现INotifyPropertyChanged，以便以后在视图中使用，并公开用于访问实体层的方法和属性。此抽象允许更改和更新实体层，而不会对ViewModel或View产生不利影响

D） ViewModel层：ViewModel类也实现了INotifyPropertyChanged，它管理视图和数据模型类之间的交互。命令和特定的视觉属性格式（比如将FirstName和LastName组合成FullName属性）出现在该层。ViewModel可以进一步抽象数据模型类，但此时不需要

E） 视图层：最终视图（窗口、页面或用户控件）。我的硬性规定是保持每个视图1个视图模型的关系（反之亦然）

我之所以称这些层是因为这是一个合乎逻辑的想法：它们的物理实现方式将取决于您的情况

---

FWIW，我最近一直在教授MVVM，并巩固了我对体系结构的看法。我在教授MVVM时首先要说的是，实现MVVM的方法和实现MVVM的人一样多。虽然这显然有点夸张，但我们的观点是，你必须找到最适合你和你的情况的方法。

我认为你提到的是MVVM的一些方面：a）提出的问题最多，B）达成的共识最少

该模式包含三个层：模型是数据，视图是屏幕，ViewModel位于它们之间。我开始认为这是不准确的，或者至少不是最优的。从数据到屏幕，我的目标是：

A） 服务层：此代码可以是实际的服务或围绕ADO.NET调用的包装器。无论是什么风格，它的工作都是与物理数据源交互。它使用实体（不一定是EF类，只是表示数据库的类）来实现这一点

B） 实体层：这些是由服务层获得的类。与物理数据源之间的所有通信都是通过这些实体类进行的

C） 数据模型