MVVM澄清

我们将要编写我们的第一个WPF应用程序，并逐渐熟悉MVVM模式。我们已经构建了许多Winform应用程序，并拥有对我们非常成功的体系结构。我们在转换该架构或确定我们的架构的某些部分适合MVVM模型时遇到了一些麻烦。

从历史上看，我们有一个Gui（主exe），然后它可以与BusinessLogic dll通信。BusinessLogic通过Web服务与DAL dll通信，并且DAL与数据库进行交互。DAL，BusinessLogic和GUI都引用相同的BusinessObjects dll。

AsIs架构

向MVVM的某些过渡相当简单。我们的Gui将仍然包含视图，我们的BusinessOjbects将仍然包含模型，而我们的DAL将仍然与数据库交互（尽管实现它们的技术可能会发生变化）。

我们不确定的是我们的BusinessLogic组件。从历史上看，这将提供GUI调用的函数，然后在视图中填充控件（即GetCustomerList，它将返回Customer对象或典型的CRUD函数的列表）。

我们主要遇到的问题是MVVM模式是否需要一个附加组件来容纳ViewModels，还是我们只是改变了思维方式并将用作BusinessLogic组件的内容迁移到ViewModels？

我们的BusinessLogic组件代表ViewModels吗？

architecture mvvm

— 用户名
source

这听起来有点像寻找问题的解决方案。为什么要转向MVVM，这是一个令人信服的原因吗？我喜欢这种模式，但是您以前的解决方案不起作用吗？视图模型就像主管演示者。它包含表示逻辑并通过数据绑定显示表面数据。它应该了解您的业务逻辑并能够延伸到该层，但是我不会将业务逻辑折叠到视图模型本身中。

— Jeremy Likness

Answers:

通常，我不会将业务逻辑放在视图模型层中。但是术语“业务逻辑”具有误导性。

埃里克·埃文斯（Eric Evans）使用的模型中，业务逻辑分为两类

域逻辑-与您要解决的实际问题域相关的逻辑
应用程序逻辑-与您正在构建应用程序的事实有关的逻辑

他提到了会计应用程序的示例。关于帐户，职位，税务帐户等的规则是域规则，即与会计域有关的规则。有关CSV导入/导出的逻辑与记帐领域无关。这些规则的存在纯粹是因为我们正在构建软件应用程序。这些是应用程序逻辑的示例。

域规则绝不应进入视图模型层。如果您遵循MVVM模式，则毫无疑问，域规则将进入模型层。

应用程序规则（例如CSV导入/导出）可以进入视图模型层。但就我个人而言，我希望将其分离到单独的应用程序逻辑层中。

视图模型应该非常简单。在相应的模型中查找视图所需的数据，在视图更改时更新模型，侦听模型中的事件，并将这些事件传播到视图中，从而允许在后台更新模型时更新视图（如果适用）。

我个人将确保视图模型层仅包含一种逻辑，即表示逻辑。

— 皮特
source

极好的答案。我喜欢确保ViewModel仅包含Presentation逻辑的观点。您可以添加与您的Eric Evans点相关的任何链接吗？

— user7676 2013年

我怀疑是否可以找到链接，因为我相信我是从他的书《域驱动设计》中获得的。无论如何，我认为这是领域逻辑和应用程序逻辑之间差异的一个很好的例子。有关这本书的更多信息，请点击这里books.google.dk/books/about/…–

— 皮特

是。

业务逻辑层由VM层表示。因此，只需迁移您的心理模型即可。

为了帮助您进行思维模型迁移，需要注意的一点是，GUI（视图）对象应绑定到VM层内的对象。该绑定转换为| 表示View不再是为了进行其他检索而“发出呼叫”的图层。数据检索的呼叫将改为来自VM。

为了更好地说明：是的，视图中的对象将需要更改，以触发进行调用的事物序列。但是View本身不会调用。在这种情况下，我认为按钮单击等同于“视图”中发生更改的某件事，但仍然无法进行通话。

在第一种情况下，该View对象将绑定到VM对象。VM应该正在侦听绑定对象上的属性更改事件。然后可以将对象更改事件连接到VM函数以进行Model调用。

在第二种情况下（按钮单击事件），可以将更改（单击）事件连接到VM公开的函数调用。

无论哪种方式，总是将事件排序到VM中，然后再调用Model，然后又调用DAL / DB。

之所以提出它，是因为一些WinForm代码用于直接从WinForm GUI的代码背后对DB层进行调用。这种方法打破了MVVM提供的分隔。

感谢您的确认。我们了解View如何与ViewModel进行交互的细微差别，并将继续使用绑定模型并删除“调用”。

— user7676 2013年

我注意到这个答案失去了赞成票。我很好奇，如果下降者会评论为什么？或者，如果他们不同意这个观点，则可以添加自己的答案。

— user7676 2013年

我同意业务逻辑层由VM层表示，但是我认为答案的某些部分可能会造成混淆。该View层旨在作为ViewModel或Model的可视化表示，因此与其说click事件已连接到VM上的函数调用，不如说是一个更好的定义，是说VM中的Command被渲染为Button。视图层。另外，我通常不希望我的模型层能够直接访问DAL，因此我的应用程序流程通常会转到VM -> DAL -> DB，并且VM和DAL都使用纯Model数据对象。

— Rachel

我不同意这个答案。ViewModel是视图的模型，它包含视图逻辑而不是业务逻辑。ViewModels是表示层的一部分

— simoraman 2013年

@simoraman- MVPVM模式符合您的建议。我认为MVPVM是一个很好的模式，但对于较小的应用程序来说有点麻烦。我真的会鼓励您将您的想法变成答案，并为这个问题做出贡献。

没错，您实际上将用ViewModel层替换BusinessLogic dll，但是我认为您将面临的最大区别是View / UI层如何与ViewModel / BusinessLogic层交互。

在WinForms中，GUI是您的应用程序，并负责应用程序流程。在WPF / MVVM中，您的ViewModels是您的应用程序，而GUI成为与ViewModels交互的用户友好界面。

例如，对于WinForms，您可能有一个DataGrid和一个Button，并且当您单击该Button时，您会调用BusinessLogicLayer.GetProducts()并将生成的Product对象加载到DataGrid中。

使用WPF，您将拥有一个包含一个ObservableCollection<Products>和的ViewModel，ICommand GetProducts执行该命令将调用DAL并加载产品集合。但是要为此提供一个用户友好的界面，您将创建一个View，该View使用用于Products集合的DataGrid和用于GetProducts命令的Button来呈现ViewModel。

实际上，我为我的博客写了一篇相当新的文章，内容涉及博客上从Winforms迁移到WPF时的心态变化，我认为总结这些差异的最好方法是使用以下图片：

— 瑞秋
source

我同意GlenH7，对于使用WPF的人来说，这是一个很好的答案。我们得到了View和ViewModel之间的交互的范式转换，因此这并不是我提出的问题的真正话题。

— user7676 2013年