EventToCommand 传递 EventArgs 是不好的做法吗？
我最近一直在使用 Silverlight 4 的 MVVM light 工具包。
我真的很喜欢其中包含的 EventToCommand 行为，它让生活变得更加轻松。我一直想知道的一件事是设置 PassEventArgsToCommand="True" 是否是一种不好的做法，因为它将特定的 RelayCommand 与视图中的特定事件联系起来。
例如，如果我的 RelayCommand 定义为：
public RelayCommand<System.Windows.Input.KeyEventArgs> myCommand
那么这只能由 KeyUp、KeyDown 等事件调用。
我认为 ViewModel 没有 UI 知识（例如公开布尔转换器并使用转换器将其更改为可见性），PassEventArgsToCommand 不会破坏这一点吗？
I've recently been using the MVVM light toolkit for Silverlight 4.
I really like the EventToCommand behaviour that is included, it makes life a lot easier. One thing I've been wondering about is if setting PassEventArgsToCommand="True" is bad practice as it will tie a particular RelayCommand to a particular event in the View.
E.g. If my RelayCommand is defined as:
public RelayCommand<System.Windows.Input.KeyEventArgs> myCommand
Then this can only be called by a KeyUp, KeyDown etc event.
I thought the ViewModel was to have no UI knowledge (e.g. expose a boolean converter and use a converter to change that to a Visibility), doesn't PassEventArgsToCommand break this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
ViewModel 是视图的模型，因此您所指的状态是视图必须具有或应表示的数据，然后 ViewModel 应该处理它。
使用 Visibility 枚举来表示视图的哪一部分应该被视为与视图的状态有关，这可能是合理的。
至于 KeyEventArgs，它来自用户的操作，代表命令的某种状态，如果您需要知道按下了哪个键，那么 ViewModel 可以合理地期望它来处理。
如果您引入更多抽象和复杂性来删除此事件参数，那么您可能会遇到未来的维护问题，前提是您可以使用此命令对其进行单元测试。
我唯一不会使用 Visibility 或 KeyEventArgs 等的情况是，如果我想对其他 UI 技术使用相同的 ViewModel。如果这是你的情况，那么我将创建抽象（尽管根据我的经验，这种情况很少见，并且通常会涉及他们自己的 ViewModel）。
The ViewModel is the model for the view so where you are referring to state that the view must have or data it should represent then the ViewModel should handle it.
It could be reasonable to use the Visibility enumeration to represent what part of the view should be viewed as that is about the state of the view.
As for the KeyEventArgs, this has come from an action from the user and represents some state of the command which if you need to know what key was pressed then it is a reasonable expectation of the ViewModel to handle.
If you introduce more abstractions and complexities to remove this event arg then you might have future maintenance issues provided you can unit test it with this command.
The only time I would not use Visibility or KeyEventArgs or the like would be if I wanted to use the same ViewModel for other UI technologies. If this is your case then I would create the abstraction (although in my experience this is rare and would typically involve their own ViewModels anyway).
如果您想要对 ViewModel 进行单元测试，即您想要调用将 KeyEventArgs 作为参数的命令，那么将 KeyEventArgs 直接传递给 ViewModel 可能不是一个好主意。
原因是您无法在 Silverlight 中实例化 KeyEventArgs（至少据我所知），因为 KeyEventArgs 在 Silverlight 中没有公共构造函数。
这意味着您无法通过单元测试传递密钥。在这种情况下，最好将特定键映射到视图/XAML 中的命令，而不是仅使用 KeyDown 事件的 EventTrigger。
将此视为一种解决方案 - 它提供了一个 KeyEventToCommand 类，允许您直接在 XAML 中将键映射到命令。
http://mvvmlight.codeplex.com/discussions/252898
It might not be a good idea to pass the KeyEventArgs directly to your ViewModel if you want to unit test the ViewModel - i.e. you want to invoke a command that takes KeyEventArgs as a parameter.
The reason for this is that you can't instantiate KeyEventArgs in Silverlight (at least not as far as I could see) because KeyEventArgs has no public constructor in Silverlight.
This means you can't pass a key from your unit test. In this situation it may be better to map the specific key(s) to the command in your view / XAML rather than just using an EventTrigger for the KeyDown event.
See this as one solution - this provides a KeyEventToCommand class that allows you to map the keys to commands directly in the XAML.
http://mvvmlight.codeplex.com/discussions/252898
将 ViewModel 与 View 解耦的一种方法是使用“代理”——中介两者之间的通信。我使用MVVMLight的Messenger类来实现消息代理，效果良好。
HTH，indyfromoz
One way to decouple the ViewModel from the View is to use a "broker" - something that mediates the communication between the two. I have used MVVMLight's Messenger class to implement a message broker with good results.
HTH, indyfromoz