0

我需要一个跟踪更改的视图模型，以便用户可以看到响应编辑和回滚部分的视觉变化。现在，我“打开”更改跟踪作为视图模型构造函数的最后一步（必要的，因为有时视图模型是从模板构造的，或者具有PropertyChanged在构造完成之前触发的默认逻辑，错误地导致人们认为它是甚至在用户做任何事情之前就改变了）。

这在大多数情况下都有效，

  • 但控制、绑定比较复杂，第三方产品对各种事件的顺序缺乏控制
  • 并且，在从服务调用（即模型模型）返回的 DTO 构建视图模型之后，需要打开更改跟踪，

有没有更好的地方打开更改跟踪？

4

2 回答 2

0

在理想的 MVVM 实现中，没有更好或替代的地方，因为您不太可能知道视图何时或如何与视图模型通信。事实上，视图模型不应该对视图有任何了解。视图可能是 Silverlight UI 或控制台应用程序，或测试模型，或其他任何东西。根据当时的一般想法，构造函数似乎是唯一应该禁用“更改跟踪”的地方。

如果您尝试严格遵循 MVVM，您应该接受您的视图模型作为主要对象和视图作为次要对象。我的意思是视图不应该引入任何与特定视图实现无关的逻辑。它只显示当前视图模型状态并将用户的操作传达给视图模型。如果这是真的，那么除了构造函数之外，您不需要关闭更改跟踪。

当然，在现实世界中，这可能很难遵循。如果您找不到其他解决方案，您可以向视图模型引入额外的属性，例如IsViewInitialized，这将打开“更改跟踪”，并使视图根据需要设置属性。

但你最好尽可能避免这种情况。这种方法增加了视图和视图模型之间的耦合，这违背了 MVVM 模式的主要思想之一。

如果您亲自问我，我的视图模型很少有用于初始化步骤的替代逻辑，如果有，则仅在构造函数中。而且我通常不会“关闭更改跟踪”，而是直接设置一些字段来绕过在大多数情况下驻留在属性设置器中的常规更改跟踪代码。但有时即使在构造函数中触发某些属性的逻辑会更方便。

于 2011-12-12T18:02:57.463 回答
0

通常，没有“正确”或“错误”的地方来处理更改跟踪。

但是，如果您更喜欢在 VM 中执行此操作，您的 RaisePropertyChanged() 方法可以累积已更改属性的列表 (changesList)。您应该实现公共（可能是虚拟）方法 ApplyChanges()，它会清除此列表并保存数据（如果您通过网络发布更改，请添加更多检查，这样您就不会一遍又一遍地发送相同的数据）。另外，有公共财产 bool IsChanged { get; }，返回 changesList.Any() - 您可以使用此属性将“应用”按钮绑定到。

对于您的情况：在复杂的构造函数中，调用 ApplyChanges() 以重置 IsChanged 状态，并且在将复杂控件绑定到您的 VM 后，还调用 ApplyChanges() - 即使您知道用户还没有做任何事情。

于 2015-12-30T08:42:47.793 回答