WPF 中的独立命令对象
将 WPF 命令作为独立对象实现是否可能/实用？如果是这样，通常是如何完成的？我看到的大多数有关命令的示例通常都涉及使用 RoutedCommand、RoatedUICommand 或 ICommand 的其他实现（如 RelayCommand）。这些命令在 MVVM 模式中的工作方式是通过属性公开这些类型的命令之一的实例。在 ViewModel 内部，命令的逻辑作为 ViewModel 上的方法实现，然后作为委托传递给命令对象。
据我了解，“经典”命令模式是将每个命令实现为其自己的独立对象，例如 OpenCustomerViewCommand。由于逻辑将完全封装在它自己的对象中，因此它可能会在我的应用程序的其他部分中重用。例如，如果我可以从应用程序中的多个位置打开 CustomerView，那么在可以访问 CustomerView 的每个 ViewModel 上简单地创建 OpenCustomerViewCommand 的实例可能会有所帮助，而不是将该方法复制并粘贴到每个 ViewModel 中，并将委托传递给 RelayCommand。如果我理解正确的话，预定义的应用程序命令（例如剪切和粘贴）的行为方式就是这样。
对我来说，必须在 ViewModel 内部提供逻辑似乎会稍微削弱命令模式的价值。我想我并不真正理解这样做与背后的代码实现 UI 事件的命令处理程序之间的主要区别。我是否应该使用 RoutedCommand 模式而不是上面描述的更经典的方法？
Is it possible / practical to implement WPF commands as standalone objects? If so, how is this typically done? Most of the examples I see about commanding typically involve using RoutedCommand, RoutedUICommand, or some other implementation of ICommand like RelayCommand. The way these commands work in the MVVM pattern is to expose an instance of one of these types of commands through a property. Inside the ViewModel, the logic for the command is implemented as a method on the ViewModel and then passed as a delegate to the command object.
The "classic" Command pattern as I understand it would be to have each command implemented as it's own standalone object, such as an OpenCustomerViewCommand. Since the logic would be completely encapsulated in its own object, it could potentially be reused in other parts of my app. For example, if I could open the CustomerView from several places in my app it might be helpful to be able to simply create an instance of the OpenCustomerViewCommand on each ViewModel where the CustomerView could be accessed, rather than copy and paste that method into each ViewModel, and pass the delegate to a RelayCommand. If I understand correctly, the predefined ApplicationCommands such as Cut and Paste behave this way.
To me, having to provide the logic inside the ViewModel seems to diminish the value of the command pattern a bit. I suppose I don't really understand the major difference between doing it this way, and having a code behind that implements command handlers for UI events. Is there any reason I should be using the RoutedCommand pattern over the more classic approach I described above?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您可以执行此操作，但需要某种适当路由请求的方法。
在您的示例中，只要
OpenCustomerViewCommand知道如何以及在何处打开“客户视图”，您就可以轻松地在任何地方重用它。您可以直接实现ICommand并添加逻辑来执行此操作，而不是使用像RelayCommand这样的类。但问题是，大多数命令往往更像是 xaml 的适配器，用于执行 ViewModel 特定的功能。在我工作过的大多数应用程序中，往往很少有真正需要重用的命令 - 大多数命令都与相关 ViewModel 的特定功能相关。因此，像 RelayCommand 这样的东西使得连接起来相当容易。
You could do this, but it requires some method of routing the request appropriately.
In your example, provided the
OpenCustomerViewCommandknows how and where to open the "Customer View", you could easily reuse this anywhere. Instead of using a class likeRelayCommand, you can just implementICommanddirectly and add your logic to do this.The problem, however, is that most commands tend to be more of an adapter for xaml to execute ViewModel-specific functionality. In most applications on which I've worked, there tend to be few commands that really need the reuse - most commands are tied to functionality specific to the ViewModel in question. As such, something like RelayCommand makes hooking this up fairly easy.