为了尽量减少代码背后的内容，我希望将一些事件逻辑转换为附加行为。我已经阅读了this article，虽然我想要实现类似的功能，但我不确定如果行为影响多个控件，我将如何继续。
示例：我们的应用程序具有侧栏，用户可以通过按钮停靠在左侧或右侧。如果按钮被触发，我们的事件将触发并相应地重新排列控件。这很容易与后面的普通代码一起使用，因为我可以访问视图中的所有控件。
现在，我会在该按钮上添加一个附加行为来处理这种情况，但是我需要访问其他控件来更改它们的位置。这可能与附加行为有关（如果是，如何？），还是有其他可能性或模式来做到这一点？
答案 0 :(得分：1)
后面的代码并不像视图模型（或数据上下文）和视图之间的耦合一样糟糕，而且似乎你完全具有（在后面的代码中实现）。您应该尝试从视图中解耦视图模型（或数据上下文），并且需要在视图模型中引入描述布局的属性（例如DockingPosition）。然后，视图应使用数据绑定到这些属性并相应地修改布局。您会发现触发器和可视状态管理器可能在这里有所帮助。 （作为额外的好处，您将能够为布局更改设置动画，以获得更好的用户体验。）
如果你成功地做到了这一点，你会发现你可以摆脱很多代码（背后的错误代码引入了很多耦合）。如果此时，您仍然有一些代码背后的代码将文本框更改为仅数字文本框，您可以将其重构为附加行为，使行为可重用并且能够在XAML中以声明方式使用。
行为附加到单个DependencyObject，并且您很少尝试使用行为来连接多个控件。
答案 1 :(得分：1)
要明确的是，MVVM方法中没有任何内容表明无法使用后面的代码。 MVVM中的首要原则是提供关注点，使我们能够分别从视图中测试视图模型。
但是，您的SideBar控件听起来像是提供了UI功能而不是数据操作功能，在这种情况下，视图模型不需要了解它的任何信息。因此，任何可能在其代码中的代码都不应该与视图模型测试一起进行测试，因此它非常适合它。
我通常遵循这个简单的规则：
如果某个特定视图只是一个在其他视图中使用的控件 并且只提供了一些小的UI功能，那么我将功能放在其代码中而不是视图模型中。
一个示例可能是一个FeedbackControl控件，它只是为用户提供反馈，或者控件只是为了方便而只包含一些其他标准控件。