MVVM：视图模型和业务逻辑连接 [英] MVVM: ViewModel and Business Logic Connection

问题描述

我所做的过去：
使用

使用MVVM模式做了几个项目之后，我还在与视图模型的作用挣扎模型只是作为一个数据容器。
把逻辑来操纵视图模型的数据。 （多数民众赞成在业务逻辑吧？）
体质：逻辑是不能重复使用

我想要现在：
保持​​视图模型薄越好。
迁移所有的逻辑放到模型层。
只保留表示逻辑的视图模型。
体质：使UI通知真的痛苦如果数据模型层内更改

所以，我会给你一个例子，以使其更清晰的：

情景：
工具来重命名文件。
类：
档：代表每个文件;
规则：包含逻辑如何重命名文件;

如果进出口下面的方法1：与
创建一个视图模型的文件，规则的视图 - > RenamerViewModel。
把所有的逻辑在RenamerViewModel：
含FileViewModel和RuleViewModel的名单和程序逻辑。
方便快捷，但不能重复使用

如果进出口下面的方法2：
。建立一个新的模型类 - >更名，其中包含一个列表文件中，规则UND诉讼逻辑每个文件interate过来，应用每个规则。
创建一个视图模型的文件，规则和更名。
现在RenamerViewModel仅包含更名模型的一个实例，加上两个ObservableCollections包住更名的文件UND规则列表。
，而整个逻辑是在更名模型。因此，如果更名模式被触发操纵一些数据通过方法调用，视图模型完全不知道哪些数据操纵。
，因为模型犯规包含任何的PropertyChange通知，我会避免。
所以商业和表示逻辑分开，但是这使得它很难通知UI。

解决方案

把业务在视图模型里面的逻辑是一个非常糟糕的方式做事情，所以我要去快说从来没有做到这一点并转移到讨论第二个选项。

把逻辑模型内部更加合理，这是一个很好的出发途径。哪些缺点？你的问题说：

因此​​，如果更名模式被触发，处理由法
调用一些数据，视图模型没有线索哪些数据操纵。由于
型号犯规包含任何的PropertyChange通知，我将
避免这种情况。

好了，让你的模型实施 INotifyPropertyChanged的肯定会让你移动到更好的东西。然而，这是真的，有时候这是不可能做到这一点 - 例如模式可能是一个分部类，其属性是自动生成的一个工具，并不会引发更改通知。这是不幸的，但不是世界的末日。

如果你想买东西，然后的有人的有付出代价;如果它不是，让这样的通知，那么你只剩下两种选择模式：

1. 视图模型知道哪些型号的操作（可能）引起的变化，它每一个这样的操作之后更新其状态。


2. 其他人知道哪些操作引起的变化，他们通知视图模型来更新它包裹的变化模型后的状态。

第一个选项又是一个坏主意，因为实际上它会回把业务逻辑的视图模型内。没有那么糟糕，因为投入的所有的在视图模型的业务逻辑，但仍。

第二个选项是更有前途（不幸的是更多的工作实现）：

• 把你的业务逻辑的一部分在一个单独的类（服务）。 。将实现全业务运营的服务，您会希望通过适当的模型实例工作执行


• 这意味着，服务知道当模特属性可能会改变（这是确定：模型+服务==业务逻辑）


• 该服务将提供有关改变模式，以所有有关方面的通知。你的ViewModels将采取对服务的依赖，并收到这些通知（因此，当自己的模式已被更新，他们就知道了）。


• 由于业务操作也由服务实现的，这仍然是很自然的（例如，当一个命令被调用的视图模型反应调用该服务的适当方法;请记住，视图模型本身并不了解业务逻辑）。

有关这种实现的详细信息见我的答案的这里和的这里。

After doing a few Projects using the MVVM Pattern, Im still struggling with the Role of the ViewModel:

What I did in the past: Using the Model only as a Data Container. Putting the Logic to manipulate the Data in the ViewModel. (Thats the Business Logic right?) Con: Logic is not reusable.

What I'm trying now: Keeping the ViewModel as thin as possible. Moving all Logic into the Model Layer. Only keeping presentation Logic in the ViewModel. Con: Makes UI Notification realy painful If Data is Changed inside the Model Layer.

So I will give you an Example to make it more clearer:

Scenario: Tool to Rename Files. Classes: File : Representing each File; Rule: Contains Logic how to Rename a File;

If Im following approach 1: Creating a ViewModel for File, Rule and the View -> RenamerViewModel. Putting all Logic in the RenamerViewModel: Containing a List of FileViewModel and RuleViewModel and the proceeding Logic. Easy and fast, but not reusable.

If Im following approach 2: Creating a new Model Class -> Renamer, which contains a List of File, Rule und the proceeding Logic to interate over each File and apply each Rule. Creating a Viewmodel for File, Rule and Renamer. Now the RenamerViewModel only contains an instance of Renamer Model, plus two ObservableCollections to wrap the File und Rule List of the Renamer. But the whole Logic is in the Renamer Model. So if the Renamer Model is triggered to manipulate some Data by Method Calls, the ViewModel has no Clue which Data is manipulated. Because the Model doesnt Contain any PropertyChange Notification and I will avoid that. So the Business and Presentation Logic is seperated, but this makes it hard to notify the UI.

解决方案

Putting business logic inside the viewmodel is a very bad way to do things, so I 'm going to quickly say never do that and move on to discussing the second option.

Putting the logic inside the model is much more reasonable and it's a fine starting approach. What are the drawbacks? Your question says

So if the Renamer Model is triggered to manipulate some Data by Method Calls, the ViewModel has no Clue which Data is manipulated. Because the Model doesnt Contain any PropertyChange Notification and I will avoid that.

Well, making your model implement INotifyPropertyChanged would certainly let you move on to better things. However, it's true that sometimes it is not possible to do that -- for example the model may be a partial class where properties are auto-generated by a tool and don't raise change notifications. That's unfortunate, but not the end of the world.

If you want to buy something then someone has to pay for it; if it's not the model that gives such notifications then you are left with only two choices:

1. The viewmodel knows which operations on the model (possibly) cause changes and it updates its state after each such operation.
2. Someone else knows which operations cause changes and they notify the viewmodel to update its state after the model it is wrapping changes.

The first option is again a bad idea, because in effect it is going back to putting "business logic" inside the viewmodel. Not as bad as putting all the business logic in the viewmodel, but still.

The second option is more promising (and unfortunately more work to implement):

• Put part of your business logic in a separate class (a "service"). The service will implement all business operations you will want to perform by working with model instances as appropriate.
• This means that the service knows when model properties may change (this is OK: model + service == business logic).
• The service will provide notifications about changed models to all interested parties; your viewmodels will take a dependency on the service and receive these notifications (so they will know when "their" model has been updated).
• Since the business operations are also implemented by the service, this remains very natural (e.g. when a command is invoked on the viewmodel the reaction is calling an appropriate method on the service; remember, the viewmodel itself does not know about the business logic).

For more information on such an implementation see also my answers here and here.

这篇关于MVVM：视图模型和业务逻辑连接的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！