为什么偏爱 RelayCommand 而不是 RoutedCommand?

发布于 2024-12-11 10:05:19 字数 800 浏览 0 评论 0原文

我正在尝试学习 MVVM 软件设计模式。我有 Matthew MacDonald 的书“Pro WPF in C# 2010”来更好地学习 WPF。在尝试开始学习 MVVM 时,我查看了 WindowsClient.net 网站,特别是 Todd Miranda 的视频“如何:使用 MVVM 模式构建数据驱动的 WPF 应用程序”。在其中,他简要讨论了 RoutedCommand,但根据 ICommand 接口编写了自己的名为 RelayCommand 的类的实现。

这看起来很有希望,但我遇到了一个问题,因为我正在开发的窗口(带有文本框的简单窗口,以及使用用户输入的参数进行搜索并在列表框中返回结果的按钮)比托德做了什么。基本上,我找不到一种方法来获取用户在我编写的 RelayCommand 类中输入的搜索参数,该类返回一个我称为 AllClients 的 ObservableCollection (显示在列表框中)。

MacDonald 的书讨论了 RoutedCommand,尤其是 RoutedUICommand,坦率地说,这看起来对我正在尝试做的事情很有希望。然而,为了更好地理解 MVVM 模式,我快速浏览了 Amazon 上有哪些书籍可以帮助学习 MVVM 模式,并找到了一些书籍,例如 Gary Hall 所著的《Pro WPF 和 Silverlight MVVM》。在那本书中,霍尔似乎强烈建议 RoutedCommand 路线不是正确的选择。这是有问题的,因此最好使用 RelayCommand。

嗯,坦白说,我真的很困惑。首先,我根本不理解霍尔的论点。为什么使用 RoutedCommands(或者可能还有 RoutedUICommands)是一个糟糕的选择?为什么使用 RelayCommands 如此优越?

I'm trying to learn the MVVM software design pattern. I've got Matthew MacDonald's book, "Pro WPF in C# 2010" to learn WPF better. In trying to start learning MVVM I've looked at the WindowsClient.net website, especially Todd Miranda's video, "How Do I: Build Data-driven WPF Application using the MVVM pattern". In that he discusses briefly the RoutedCommand, but writes his own implementation of a class called RelayCommand based upon the ICommand interface.

This looked promising, but I've got a problem in that the window I'm developing (a simple window with textboxes, and button to issue a search using the parameters entered by the user and returning results in a listbox) is more complicated than what Todd did. Basically, I can't find a way to get the search parameters entered by the user in the RelayCommand class I've written which returns an ObservableCollection I call AllClients (that gets displayed in the listbox).

MacDonald's book discusses the RoutedCommand and especially the RoutedUICommand, and frankly this looks various promising to what I'm trying to do. However, again in an effort to better understand the MVVM pattern I've taken a quick look at what books might be available to help learn the MVVM pattern on Amazon and found some books like, "Pro WPF and Silverlight MVVM" by Gary Hall. In that book Hall seems to strongly suggest that the RoutedCommand route is not the way to go. That it is problematic and therefore it is better to use the RelayCommand.

Well, frankly, I'm really confused. First, I don't understand Hall's argument at all. Why is using RoutedCommands (or presumably RoutedUICommands as well) such a bad alternative? Why is using RelayCommands so superior?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

折戟 2024-12-18 10:05:19

一般来说,我发现 RoutedCommand 通常过大。 WPF ICommand 与 RoutedCommand 中对其功能有很好的解释。

我认为,RelayCommand 的优越性来自于它的易用性和简单性。它仅使用视图模型中的 Execute 和可选的 CanExecute 事件处理程序进行实例化。在我只想将某些功能连接到按钮、菜单项等的情况下,这一直很好。

如果您有任何需要传递命令的参数,我建议将它们放在视图模型中,靠近命令实现所在的位置。例如,对于搜索命令,您将有一个文本框绑定到视图模型中包含搜索文本的字符串属性。当调用命令的 Execute 事件处理程序时,它将获取该属性的值并将其传递给您在模型中实现的搜索例程。因此,我认为没有必要使用命令的 Parameters 属性。视图模型方法更加灵活并且允许多个参数。

Generally speaking, I have found that RoutedCommand is often oversized. There is a good explanation of its power in WPF ICommand vs RoutedCommand.

The superiority of RelayCommand, I think, comes from its ease of use and straightforwardness. It is instantiated with just an Executeand optionally a CanExecute event handler in the view model. This has always been just fine in situations where I just wanted to hook up some functionality to a button, menu item and the like.

If you have any parameters you need to pass the command, I would suggest having them in your view model, next to where the command implementation is located. For a search command, for instance, you would have a text box bound to a string property in your view model that contained the search text. When your command's Execute event handler is invoked, it would take that property's value and pass it to the search routine you have implemented in your model. I thus don't see a need to use the Parameters property of a command. The view model approach is just more flexible and allows for multiple parameters.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文