MVVM澄清

Question

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

历史上，我们有一个Gui (主exe)，然后与BusinessLogic dll通信。BusinessLogic通过web服务与DAL dll通信，DAL与DB交互。DAL、BusinessLogic和GUI都引用相同的BusinessObjects dll。

一些过渡到MVVM是相当直接的。我们的Gui仍然包含视图，我们的BusinessOjbects仍然包含模型，我们的DAL仍然会与DB交互(尽管实现它们的技术可能会改变)。

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

我们的主要挂起是MVVM模式是否需要一个额外的组件来容纳ViewModels，还是只需要改变我们的想法并将我们作为BusinessLogic组件使用的组件迁移到ViewModels？

我们的BusinessLogic组件是否表示ViewModels？

Answer 1

通常，我不会将业务逻辑放在视图模型层。但是“商业逻辑”这个词是误导的。

Eric Evans使用一种模型，其中业务逻辑分为两类。

• 领域逻辑-与您正在解决的实际问题域相关的逻辑。
• 应用逻辑-与事实相关的逻辑，您正在构建一个应用程序。

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

域规则不应进入视图模型层。如果您遵循MVVM模式，那么域规则就会毫无疑问地进入模型层。

应用程序规则，如CSV导入/导出，可以进入视图模型层。但就我个人而言，我更愿意将其分离到一个单独的应用程序逻辑层。

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

就我个人而言，我将确保视图模型层只包含一种类型的逻辑，即表示逻辑。

Answer 2

是。

业务逻辑层由VM层表示。所以就转移你的心理模型。

为了帮助您的心智模型迁移，一个细微的差别是GUI (View)对象应该绑定到VM层中的对象。这个绑定转换为\\意味着视图不再是为了检索其他东西而“进行调用”的层。数据检索的调用将来自VM。

为了更好地解释:是的，视图中的一个对象将需要改变，以触发进行调用的事物序列。但是视图本身并没有发出呼叫。在这种情况下，我认为按钮单击等同于视图中的更改，但仍然不进行调用。

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

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

无论哪种方式，它都是一个事件，它会序列到VM中，然后调用模型，然后调用DAL / DB。

我之所以提出这个问题，是因为一些WinForm代码习惯于直接从WinForm GUI的代码背后调用DB层。这种方法打破了MVVM提供的分离。

Answer 3

实际上，您将使用BusinessLogic层替换ViewModel dll，这是正确的，但是我认为您将面临的最大区别是视图/UI层与视图模型/业务逻辑层的交互方式。

在WinForms中，GUI是您的应用程序，负责应用程序流。在WPF/MVVM中，您的ViewModels就是您的应用程序，而GUI只是一个用户友好的界面，可以与ViewModels交互。

例如，使用WinForms，您可能有一个DataGrid和一个按钮，当您单击该按钮时，您将调用BusinessLogicLayer.GetProducts()并将生成的Product加载到DataGrid中。

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

实际上，我最近为我的博客写了一篇关于从Winforms到WPF在我的博客上的转变的文章，我认为最好的方法就是用这些图片来总结两者之间的区别：