我正在学习和理解WPF编程中使用的MVVM模式的理论和用法。
来自WinForms,我仍然倾向于只需双击一个按钮即可将我带到点击的事件处理程序。
在线阅读MVVM,显然这应该永远不会完成,因为,嗯......我不确定。建议人们应该使用ICommand接口来封装UI / View调用的动作。
我还没有阅读为什么这是首选。如果你使用事件处理程序,你仍然没有打破View / ViewModel关系,因为ViewModel仍然不知道View ...对吗?
使用命令是否会为事件处理程序提供一些额外的灵活性?如果有的话,我觉得使用命令会使代码更加严重,因为你必须回溯才能找到ICommand逻辑。使用事件处理程序,它可以在View后面的代码中找到。我错过了什么吗?
因此,基本上,使用事件处理程序而不是命令会违反MVVM模式吗?
答案 0 :(得分:4)
使用事件处理程序,可以在View后面的代码中找到它。
这正是你必须避免的。
您的应用程序的逻辑(或者更糟糕的是,您的业务逻辑)不属于UI,不应该放在代码后面。这就是ViewModel命令存在的原因。
当然,如果您的按钮触发动画或执行任何其他UI特定任务,那么是的,处理事件处理程序并将该代码放入UI中是有意义的。
是的,如果你来自winforms,正确地分离关注点并避免混合用户界面和其他应用程序可能看起来有点参与,但是一旦你理解了这有助于产生非常干净,它真的会得到回报代码,以及如何100%自定义UI,而无需更改应用程序逻辑中的单行代码。
另外,你的感觉
你必须回溯才能找到ICommand逻辑
也是由于你的winforms背景,你的注意力放在用户界面中,你以UI为中心的方式推理你的代码。在WPF中,UI是我通常构建的最后一件事,因为它只是我已经以Models和ViewModel的形式构建的数据和逻辑的不言而喻的表现形式。我的注意力不在于UI,而是在我的应用程序处理的实际数据和逻辑中。
这意味着我不会花费大量时间研究UI特定的类,除了动画和交互性等UI特定事项之外的其他任何内容。
答案 1 :(得分:1)
这实际上取决于您在点击按钮时想要做什么。
如果您只是想与U.I进行互动。 (例如,改变控件的可见性或其他属性)然后只有顽固的MVVM纯粹主义者会反对这一点。
但是,如果您想要执行与模型或其他数据相关的任何事情,那么这将违背MVVM在关注点分离方面所代表的一切。