WPF MVVM代码背后
我尝试在我的WPF MVVM项目中避免代码隐藏在视图中。
但是我有一些非常具体的观点。 例如，当控件获得焦点时，我希望突出显示全文（即使用户单击文本框）。
在这里，我可以选择在视图模型中处理这个问题（然后需要了解视图，我想避免这种情况）。
我还有一些其他的代码，当用户在键盘上向左或向右按下时（而它们只对视图进行更改，而不是模型或视图模型）对UI做了一些事情，我再次想到最好的地方因为这些是在视图背后的代码中。
所以我问的是代码是否只影响视图（例如光标移动，选择文本框中的所有文本等等，而不是模型或视图模型，是否可以将其放在代码中，而不是比其他地方。
想知道这里的最佳做法是什么，或者是否有其他人有更好的建议在哪里放置此代码。
如果行为仅与UI相关，则不应将其放在ViewModel中。 你给出的突出显示的例子是这种情况的一个很好的例子。 话虽如此，我建议你避免重复你的代码（例如）创建一个自定义控件，当它有焦点时突出显示文本。 这样，您可以在尽可能多的视图中重用控件，您的视图可以避免代码隐藏，如果您优化控制，优化就会全面发生。
编辑：
根据Ravi的回答，Behaviors也是一种引入UI相关逻辑的方法，同时让View免于代码隐藏。 但是，如果您发现自己反复声明具有相同行为的相同控件，我认为最好创建一个包含该行为的控件。
话虽如此，如果所述UI逻辑在一个视图中只出现一次，您可以考虑将其置于代码隐藏中。 虽然很少提前知道你不会在其他地方需要那种逻辑。
编辑：
我认为@ ken2k使用强烈的鼓励是指不将它放在我也提倡的ViewModel中。 正如他所说，UI逻辑应该在View中实现。 现在，有几种方法可以做到这一点。 其中之一是直接在代码隐藏中编码，这可能导致重复的代码和维护问题。 此外，如果您使用unit testing，它可能会让您陷入困境。 第二种是将这种逻辑编码为行为，这是封装UI代码的好方法。 然后，您可以对行为进行unit testing，以确保其正常工作。 但是，您可以找到（正如我在许多项目中所做的那样），您已经开始使用行为标记为XAML中的每个TextBox加密。 如果这种情况开始发生，我会（并且已经）创建一个’HighlightedTextBox’控件并在我的XAML中使用它。 总之，我的建议并不与ken2k相矛盾，但它是解决在为View放置逻辑时可能遇到的一些问题的指针。
所以我问的是代码是否只影响视图（例如光标移动，选择文本框中的所有文本等等，而不是模型或视图模型，是否可以将其放在代码中，而不是比其他地方。
不仅没关系，而且强烈鼓励 。 MVVM不是为了让你在ViewModels中编写成千上万条丑陋的代码行，而是在这里使代码可测试并引入关注点分离 。
如果它与视图完全相关（您的“焦点”示例是一个完美的示例），那么只需将其写入后面的代码中即可。
使用自定义控件作为@Boluc Papuccuoglu建议，是不错的选择，但在使用之前我想让你看看这里的行为在WPF介绍
强烈建议将所有视图逻辑逻辑放在一个位置。 您应该始终在XAML和代码中保留View内容，而不是污染ViewModel 。
ViewModel职责是仅包含可以进行unit testing的数据部分 。 使用ViewModel中的UI内容，您将难以进行unit testing 。
根据MSDN中的链接，后面的代码定义：
代码隐藏是一个术语，用于描述在标记编译XAML页面时与标记定义的对象连接的代码。
如您所见， 后面的代码是您视图的部分类 。 一半是通过根元素的x:Class属性声明的，另一半是以后面的代码forms声明的。 所以，根据我的说法，所有的UI内容应该放在一个地方，你不应该在将视图内容放在代码中之后再三思而后行。 （这就是它的意思）。 MVVM从未意味着没有任何代码背后的设计。
此外，ViewModel的职责是通过数据绑定向您的视图提供数据。 它永远不应该知道UI的东西。
在这里阅读更多相关信息 – WPF中的代码隐藏和XAML 。
你想要多少代码进行unit testing？ 如果您的视图可以在控件获得焦点时触发命令，并且您的视图模型可以以编程方式触发事件以突出显示该控件中的文本，那么您将拥有使用模拟对象对该行为进行unit testing所需的一切。 即使您不想进行unit testing（或者因为您公司的bean计数器不会给您时间/预算而这样做），然后将该function放在附加行为中意味着它们可以在其他地方使用。 我不是这个网站上的其他一些硬核MVVM纯粹主义者，但我可以诚实地说，即使在我工作过的最大的企业应用程序中，我也从未见过绝对需要WPF代码隐藏的情况。 。