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