C# MVVM中WPF画布（缩放）的适当处理

给模式专家的一个问题：我正在重构一个应用程序，该应用程序分析（繁重的数学！）并在画布（窗口）上绘制大量不同的几何图形

当前，实际绘图是由画布的容器控件的ChangeSize事件触发的助手类完成的。缩放/平移由使用各种鼠标事件的类似构造处理

---

问题是：据我所知，MVVM将事件处理声明为视图模型中要处理的命令-我可以这样做，但关键是要正确定位几何体，视图模型从模型中获得世界坐标，视图模型需要知道视图画布的大小，这也是个问题。那么，在哪里（以及如何）进行绘图，特别是从世界坐标到屏幕（画布）的缩放。我看过值转换器、项目模板等——但这意味着要编写大量额外的中间代码或XAML丛林

我能找到的所有示例都有些简单（只有几个按钮或图片和标签），但如何在MVVM中正确精确地绘制几何图形？

在我看来，纯MVVM不适合您的场景。当我说纯时，我的意思是使用模型属性的绑定

为了实现该模式，您必须使用

绑定

将几何体值绑定到

画布

，并且假设您有许多需要在

画布

上渲染的形状，那么

绑定

只会导致 表演

记住，

绑定

依赖于反射，在需要绘制大量几何图形（因此需要进行大量绑定）的场景中，这将大大降低UI的速度，因此使用视图的代码简单地绘制几何图形会更快

用户界面就是用户界面，数据就是数据。我的建议是让您的视图模型进行计算，一旦计算完成，就在

Canvas

上异步绘制代码后面视图中的数据

---

MVVM不是没有代码落后，而是将代码保持在它所属的位置。在您的情况下，从视图订阅视图模型事件绝对没有错。但是如果你真的想减少依赖性，你可以使用。

“MVVM声明事件处理是邪恶的”-你从哪里得到这些谬误？MVVM只是希望职责分离：属于视图的内容，应该放在视图中，等等。命令是视图和视图模型之间通信的方式之一。它不是事件处理程序的替代品。请理解术语“事件处理”。MVVM中的ICommand或代码隐藏中的EventHandler方法只是不同的方式。您总是在当今的GUI应用程序中处理事件。此外，MVVM是Silverlight、Win Phone和WPF应用程序的首选模式，而不是强制要求。你也可以不用它来构建一个应用程序。当你不这样做时，可能会有一些例外；我不想跟随MVVM。比如你的应用程序，IMO。如果我的“邪恶”表情踩到了别人的脚趾，我会道歉——这只是对一个范例的轻松描述。是的，我确实理解“事件处理”是一个更广泛的类别……然而，我的问题是，你能和/或它是否适合编写这样一个没有代码隐藏的应用程序。