所以我在学习 MVVM 的时候偶然发现了一个问题。我有一个包含 TextBlocks 的 TreeView，当我双击 TreeView 中的任何 TextBlocks 时，我想对其执行操作。我开始学习行为，我有一个很好的例子来说明行为是如何实现的，但是这个例子根本没有将行为连接到 ViewModel。所以换句话说，如果我双击 TextBlock，我有 Behavior 类可以捕获它，但我没有任何 ViewModel 来执行任何操作。
有人可以花点时间解释一下这些是如何联系起来的吗？我正在查看这篇文章： http: //msdn.microsoft.com/en-us/library/gg430869 (v=pandp.40).aspx 但我似乎不明白我在寻找什么。
MVVM 概念为我们提供了 WPF 应用程序中的解耦机制，这意味着 xaml.cs 文件中不再有代码。附加行为是不同的事情。它与 MVVM 无关。
但是因为如果我们有我不能使用 MVVM 的场景，例如双击时选择 TextBox 的文本。这是您要在文本框上添加的行为。
您将更喜欢在 xaml.cs 文件中实现双击功能，因为它不可重用且紧密耦合。
这就是行为出现的地方。我们将为 TextBox 创建行为并将其附加。现在，您可以将此行为附加到所需的任意数量的控件。
编辑：
如果您使用的是 WPF 4.5。您可以查看事件的标记扩展
如果你想用附加的行为来做。创建具有命令依赖属性的双击事件的附加行为。您的双击行为只是提出附加的命令，并在 xaml 中将命令与 viewmodel 绑定，我希望您知道如何。
希望，我能够回答你的评论。
DJ 有一个很好的答案，尽管我想在这个讨论中加入一些额外的想法。
根据我的经验，当视图不依赖于视图模型来正常运行时，视图行为（无论是代码隐藏、附加行为、混合行为还是自定义控制逻辑）通常很有用。如果视图（UserControl、Window、Page等）在没有视图模型的情况下在逻辑上没有意义，则从视图中删除行为并将其移动到视图模型可能更有意义。
虽然我们可以用各种行为在阳光下做几乎任何事情，但这通常是不明智的。MVVM 有充分的理由限制了我们应该做的事情，以便我们可以观察关注点分离以提高应用程序的内聚性并解耦我们的类。这两件事就是软件可维护性的全部意义所在，随着应用程序成长为企业软件，这些概念变得越来越重要。
重要的是要考虑行为所带来的担忧。了解这一点将有助于我们找到合适的位置。以下是一些有助于了解其所属位置的问题：
对域模型具有依赖关系（甚至是松散耦合的行为）的行为应该可能属于视图模型（或服务），而不是视图。例如，如果行为需要保存到外部设备（例如数据库）或从外部设备读取，则它具有视图不应该具有的依赖关系。将此逻辑包装在服务函数中。或者，如果不使用高度分层的架构，请将其放在视图模型中。
出于与先前答案相同的原因，该行为可能属于视图模型或服务类。视图不应该对服务或领域模型对象有明确的了解，因为它会混淆视图所具有的职责（或关注点）。视图应该只关注用户 UI 的视觉/物理方面。许多视图应该定义一个它绑定到的契约（即视图模型接口）以便正确操作。
这是一个有点棘手的问题。很多时候，我们预见到能够对相同的内容进行不同的呈现。实际上，这些情况下的视图是一些结构的薄包装。例如，假设对于一个电子邮件应用程序，我们有一个接收电子邮件的汇总视图和一个详细视图。两种视图可能都需要支持相同的行为（例如删除、回复、转发）。因为我们在同一类型的不同视图中重用行为，所以行为应该属于一个共同的、可重用的地方。视图模型逻辑是一个很好的地方。
当需要在不同类型的视图（例如TextBox, ComboBox）中重用行为时，我们可能需要附加行为。通常，我们可以知道这一点，因为视图是如此多样化，以至于它们不可能共享一个视图模型界面。鉴于行为与视图相关的职责有关，那么自定义控制逻辑、代码隐藏、附加行为或混合行为都是合适的地方。