为什么在WPF MVVM中使用私有方法
本文关键字：有方法 WPF MVVM 为什么 | 更新日期: 2023-09-27 17:57:28
我最近接手了一个相对成熟的WPF MVVM项目的开发，该项目没有很多单元测试。因此，一旦我了解了大多数代码的作用，我就认为再写一些是个好主意。
现在，我对MVVM或WPF都没有太多经验，但很明显，考虑到UI和代码之间相对有限的、基于属性的绑定，很多逻辑可以被锁定在私有方法后面。这就是我应该做的，也是我的前任所做的。
单元测试私有方法有点痛苦（我确实知道如何使用PrivateObject，但它很笨拙），阅读有关该主题的讨论，似乎有相当多的人在宣传减少使用私有方法来促进测试。
这让我思考：将东西锁定在私有方法后面的主要原因是，其他使用该对象的开发人员不会被几乎无用的方法淹没，对吧？但在WPF MVVM中，您从XAML调用对象，在XAML中，智能感知有限，您需要在这样做之前知道所调用对象的名称。
所以。。。在这种模式下进行编码时，使用私有方法有什么好的理由吗？或者，考虑到MVVM的一个关键好处是增加了可测试性，那么公开它可能更好吗？
MVVM中的视图模型实际上是一种可以绑定到视图的模型之上的外观类型，因此视图与模型没有直接耦合。它提供了特定于视图的类型和接口，如ObservableCollection、INotifyPropertyChanged、ICommand等。XAML不能绑定到我所知道的任何私有对象。我倾向于把我认为你所描述的私人成员放在一个物理上不同的类中，我会把他们归类为"模型"（更新启动）通常，如果这类事情是私有的，那么它就是业务逻辑。（如果视图使用了它——ala命令——它们需要是公共的）（更新结束）可以独立于视图模型进行测试。
我想你会发现，一旦你这样做了，你就不会对视图模型进行太多测试，因为你实际上只是在测试ObservableCollection之类的框架元素，或者接口是否正确实现。为了让虚拟机使用该模型，其成员需要是公共的，因此是可测试的。
更新：需要明确的是，视图模型中的"逻辑"没有错——只要该逻辑直接支持视图（或其他支持视图的东西）。例如命令。
对我来说，私有成员是确保封装的方法。这是尽可能使用它们的充分理由。
关于XAML中的Intellisense，一旦您走出XAML代码背后的世界，它就从来没有特别有用过。由于视图与ViewModels的连接方式，没有编辑器（ReSharper，VS）能够支持它，而且可能永远不会支持它。想象一下，一个动态加载的子虚拟机——你能做的最好的事情就是相信你的属性路径是有效的。因此，无论是公共的还是私人的XAML都无法使用。这是对私人成员的赞扬。
PrivateObject绝对是一个黑客，但它提供了我需要的东西，使我能够保护我的VM免受私人成员不可预测的使用。