我无法找到关于这个主题的讨论，但我认为它非常重要，因此存在很大的机会，所以我很乐意阅读。
在我们的viewmodel属性设置器中，我们可以检查提供的值是否等于当前值，并且只在这种情况下通知，或者我们可以忽略检查并设置＆amp;马上通知。
虽然这个检查看起来很讨人喜欢，因为它节省了一些资源，当VM上的“刷新”不会导致View重绘时，当View稍微复杂一些并且有一些代码可能无法进行时，它也会产生一些不良影响放入VM或将其放入VM中比将其保留在View中要困难得多。
因此，根据我对MVVM的经验，我可以想到这种检查阻止某些代码按预期工作的情况。所以目前我认为这种检查是一件危险的事情，并且通常不值得利用保存重绘。
有时候这种检查可以用来代替更好的程序逻辑，例如VM上有2个实际上紧密相连的属性，比如string＆amp;某个实体的对象表示。因此，当一个设置为示例字符串时，如果正确验证，它内部也会调用对象设置器，并且此相等性检查可以保存来自对象的无限循环的情况＆lt; - ＆gt;字符串setter，但在这种情况下，我认为引入一个在setter中检查的标志更好，如果不需要则不调用另一个，当调用say object setter来自对字符串setter的调用时。
我认为这个检查主要用于我刚刚描述的场景，我认为这不是执行检查的正当理由。
那么我们应该如何对我们的制定者进行编码呢？
编辑：好吧只是为了给出一个场景，最简单也是最愚蠢的一个是：如果我们有一个OneWay绑定到来自VM的View，并且由于某种原因在View代码隐藏中存在一些处理器直接更改View，导致它要与VM不同步，刷新VM不会有帮助。当然很明显，在这种情况下我们应该调用绑定的VM setter，但我认为在某些情况下，当分辨率变得不那么透明时，场景可能会更复杂和更先进。所以场景很愚蠢但是检查会阻止正确的行为。我想更多地考虑一个现实世界的例子，它不太容易解决，但可能需要一些时间..
答案 0 :(得分：2)
根据我的个人经验，我发现这个检查非常有用，我总是在设置器中进行相等检查，以确保如果不需要刷新绑定值，那么我不应该调用属性更改而不应该强制视图在完全不需要时刷新值。
谈到你的方案，其中相等检查导致你的麻烦，我认为在场景中肯定有一些奇怪的东西，或者很可能你可能正在接近错误的东西，否则我已经使用了很多MVVM并且没有找到这样的场景我的情况。即使存在不进行等式检查可能有意义的情况，我也不会停止使用等式检查，因为在一些情况下我遇到了一个小问题。我会尝试在特定问题的情况下做一些解决方法以避免问题，而不是在setter中使用相等性检查
答案 1 :(得分：0)
一般来说，cheking是个好主意，特别是当你在更改值时触发一些事件时，它会阻止你做一些不必要的甚至是不需要的工作。 当价值相同时，我不明白为什么你想要发射事件。如果你愿意的话，那么最好先手动启动它，然后做别人可能没想到的事情。