MVVM Light - 向代码隐藏发送通知
我有我的第一个 MVVM Light 应用程序，并且我表现得非常好，并且没有在后面的代码中添加任何内容。出于性能原因，我正在使用的图表控件需要调用来关闭其更新，然后在更新图表系列后再次打开它。所以我需要从 ViewModel 调用控件上的方法。
现在，我可以通过“更大的锤子”方法实现所有这一切，通过定位器的 MainStatic 方法将对图表控件的引用传递到 ViewModel 中。我发现自己认为这确实不是应该完成的方式，我正在尝试以“MVVM 方式”做所有事情。任何 MVVM Light 大师都可以给我指路吗？我发现的只是人们将命令从后面的代码发送到 ViewModel...我需要走另一条路...或者至少我认为我这样做...;-)
I have my first MVVM Light app and I have been very good and put nothing in the code behind. For performance reasons, the chart control I am using though needs a call to turn off it's updating and then turn it on again after the chart series have been updated. So I need to call a method on the control from the ViewModel.
Now I can make all of this happen through a "bigger hammer" approach by handing a reference to the chart control into the ViewModel through the locator's MainStatic method. I find myself thinking this is really not the way this is supposed to be done and I'm trying to do everything in the "MVVM way". Can any MVVM Light guru's show me the way? All I've found poking around is people sending Commands from the code behind into the ViewModel... I need to go the other way... or at least I think I do... ;-)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
“更新”开关应该通过可绑定属性公开，而不是需要函数调用。然后，您只需通过绑定到视图模型的属性来打开和关闭它。
由于情况显然并非如此，也许您应该将图表控件包装在您自己的用户控件中或对其进行子类化（稍微困难一些）。然后，您可以公开您想要的任何属性（包括“更新”属性，其设置器调用更新方法）。
我个人对于在基本用户控件上使用非 MVVM 方法（即代码隐藏）没有任何疑虑，因为它们应该被视为更像第三方控件，而不是应用程序的一部分。对现有控件进行包装或子类化只会产生更好的可重用组件库。
The "updating" switch should have been exposed via a bindable property rather than need function calls. Then you simply turn it on and off via a binding to a property of the View Model.
As that is apparently not the case, perhaps you should wrap the chart control in your own user control or sub-class it (slightly harder). Then you can expose any properties you want (including an "Updating" property, whose setter calls the update methods).
I personally have no qualms in using non-MVVM methods (i.e. code-behind) on basic user controls, as they should be treated more like third-party controls than part of your app. Wrapping, or sub-classing, existing controls just leads to a better library of reusable components.