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

Question

我从线分叉When using MVVM pattern, should code relating to property changes go in the setter or an event?

我的MVVM模式的理解与视图和视图模型零件OK ......

但对于Model部分？它是技术对象模型（EntityFramework SelfTracking生成的类，然后位于Web服务后面，然后是服务器中的所有业务逻辑）或应用程序逻辑模型（我们将在Silverlight客户端上基于实体类当然，感谢PRISM项目链接器，它会呈现面向GUI的操作，并提供更多业务逻辑，并封装脏的技术内容以访问WS以将实体上的修改传播到数据库）？

（Personnaly，我想第二个的）

在我们的Silverlight/WCF（不RIA）的项目，我们管理的文件。我们有用于显示这些文档的视图（例如InboxView.xaml），该视图粘贴到InboxViewModel.cs中，其中包含要显示的文档列表。 InboxView中的ListBox是DataBound到InboxViewModel中的DocumentList ObservableCollection属性。但是列表框ItemTemplate是DataBound到DocumentViewModel.cs，它封装了实体生成的Document.cs类。

点是这个DocumentViewModel实际上是由其他视图使用...（对我来说部分合适，如果MVVM确实规定了Views和ViewModels之间的双射，但这不是我的观点......）。

在我看来，我宁愿有一个DocumentModel.cs而不是DocumentViewModel.cs，它可以被几个ViewModel（InboxViewModel，EditDocumentViewModel ...）共享，并封装对WS的调用以触发业务操作服务器端与客户端修改实体。然后，我们将在ViewModels（MV-VM）和视图（M-视图模型）中具有应用逻辑模型或面向GUI的模型（M -V-VM） V -VM）。所有在Silverlight方面。

但随后2个问题：

1 - 如果保留我的愚见，这将是确定直接数据绑定一个ItemTemplate到模型对象？由于没有任何视图直接绑定到DocumentModel，而是绑定到InboxViewModel（例如，它是DocumentModel对象）中的属性？

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

我的技术领导不断给我提供参考，但他/他没有给我任何答案，而且，我只是想在我自己这里思考。

感谢所有你们的...... 干杯

Answer 1

我想你触及MVVM的方面是A）求最问题和B）有共识的最低金额。

该模式意味着三层：模型是数据，视图是屏幕，ViewModel位于它们之间。我开始认为这是不准确的，或者至少是非最佳的。从数据到屏幕，这里是我正在努力的方向：

A）服务层：此代码可能是实际的服务或包装ADO.NET调用。无论风味如何，其工作都是与物理数据源进行交互。它使用实体（不一定是EF类，只是表示数据库的类）执行此操作。

B）实体层：这些是服务层获得的类。来自物理数据源的所有通信都通过这些实体类发生。 D）数据模型层：这些类包装/管理实体层。具体来说，它们实现INotifyPropertyChanged，以便稍后在视图中使用它们，并公开用于访问实体图层的方法和属性。该抽象允许更改和更新实体层，而不会对ViewModel或View产生不利影响。 D）ViewModel层：ViewModel类，它也实现INotifyPropertyChanged，管理View和Data Model类之间的交互。命令和具体的visual属性格式（比如将FirstName和LastName组合成一个FullName属性）发生在这一层。 ViewModel可以进一步抽象数据模型类，但在这一点上它不应该是必要的。 E）视图层：最终的视图（窗口，页面或用户控件）。我坚强而快速的规则是保持1 ViewModel每个视图关系（反之亦然）。

我打电话给这些图层，因为这是合乎逻辑的想法：它们如何在物理上实施将取决于您的情况。

FWIW，我最近教了很多MVVM，并巩固了我对这个架构的想法。我在讲授第一件事时说的是，实现MVVM的方法与实现MVVM的人数一样多。虽然这显然有点夸张，但这个想法表明你必须找到最适合你和你的情况的东西。