我的问题是,为什么我不能直接绑定到一个方法?
我使用了Josh Smith的RelayCommand ICommand实现,它允许您将委托注入到一个ICommand对象中,但是,是否有更简单的方法允许按钮推送调用ViewModel中的方法?
我对MVVM很新,我相信我需要一些启示。
Button
(例如)中,因为其没有接受委托的属性。相反,它具有类型为ICommand
的Command
属性。 RelayCommand
(又名DelegateCommand
)只是包装委托的ICommand
。<Button Command="{ViewModelMethod SomeMethodName}"/>
然而,这样做会更慢,并增加视图和视图模型之间的耦合。如果视图只知道类型为ICommand
的视图模型上的属性,则该命令的实现可能完全改变(或方法名称可能更改)而视图不知情。
我完全不同意。
调用速度并不重要:命令是用户交互,它们从不需要速度。
关于耦合的论点也是有缺陷的。为什么 {Binding MyProperty} 不是耦合,而 {ViewMethod MyMethod} 是呢?
需要专门制作“命令”来包装方法的要求很愚蠢。命令可能是有用的实现方式,但我们已经在C#中拥有了方法,用庞大笨重的东西替换它们是不正确的。
那个关于MarkupExtension和Binding的事情确实很困难。但它可以做到。实际上,它已经做到了,您可以查看CodePlex上的MethodCall项目:http://methodcallthing.codeplex.com/
您可以使用绑定来选择方法的“this”,并可以使用绑定来获取参数。所有这些都是实时的,即在调用命令时计算。另一个奖励功能是方法调用的推出结果,您也可以使用绑定进行此操作(OneWayToSource)。
ICommand提供了CanExecute,这对于控制启用非常重要。而简单的委托则不然。使用ICommand是明智之选。
ICommand
接口的实例。这里的静态指的是设计器在设计时不需要使用反射来证明您的命令对象实现了ICommand
接口;相反,WPF会在运行时检查UI操作是否绑定到确实实现ICommand
的对象上。
因此,在您的viewModels(应用程序逻辑)中,您可以使用自己设备的一些Command
接口,而您需要确保在运行时实例化以实现您的Command
接口的类也实现了ICommand
以使WPF满意。这样,您就可以避免在ViewModels中包含ICommand
,并且随后您可能能够避免在应用程序逻辑中引用System.Windows
。