c# - MVVM，对 ViewModelLocator 和 DataTemplate 感到困惑，导致 ViewFirst 与 ViewModel 优先

Question

我使用 MVVMLight，它带有一个 ViewModelLocator。

我最初的项目提出了以下问题。我有一个在启动应用程序时呈现的 MainView。根据单击的按钮，它通过我的 MainView 中的 ContentControl 呈现 View1 或 View2(每个都是用户控件)。

我在我的 MainViewModel 中找到了正确的 View 模型。但我发现我还需要一个 DataTemplate，以便 View1 和 View2 中的用户控件将在 MainView 中正确呈现，否则它只会显示类的基于文本的名称。

我对以下内容感到困惑:

a) 我是否需要 View 模型定位器和 DataTemplate 来完成上述任务？我刚刚跳入 WPF，但认为我读到一个或另一个是必需的，而不是两者都需要。或者更具体地说:为什么我的 View 中有 DataContext="{Binding LiveDataViewModel, Source={StaticResource Locator}}">(它解析绑定(bind)到它自己的 View 模型)但仍然需要一个 DataTemplate ？

b) 这是 View 模型优先方法还是 View 优先方法？

c) 我尝试了一个代码隐藏的解决方案，它确实花了我 4 行代码来完成完全相同的事情，这让我花了很多类(class)、弯路、eventToCommand 和转换器 [因为触发 View 选择的控件只引发事件不是命令]、数据模板、 View 模型定位器、不同的 View 模型……这看起来是一个巨大的成本，没有任何优势。将其放入代码后面在我看来非常好，因为它是纯 UI 内容(选择 View 并绑定(bind)到内容控件，完成)。我在这里错过了什么吗？我会通过隐藏代码放弃什么？

我是 WPF 和 MVVM 的新手，现在我非常沮丧，因为感觉我在绕着一个看似微不足道的问题转圈。

Answer 1

如果这个答案听起来很基础，我很抱歉，但听起来您可能仍在学习 WPF 并且误解了一些关键的事情。

首先，WPF 应用程序有两层:

• 一个 UI 层，由您在屏幕上看到的呈现的对象组成
• 以及位于 UI 后面的数据层，称为 DataContext

当您进行绑定(bind)时，您是从数据层提取数据并将其放置在 UI 层中。

ViewModelLocator 影响数据层。它用于查找放置在 UI 对象后面的适当数据对象。

现在，在数据对象直接插入到 UI 层的情况下，例如任何具有 .Content 或 .ItemsSource 属性的东西直接绑定(bind)到它的数据层， WPF 呈现数据对象的默认方式是使用显示对象的 .ToString() 的 TextBlock。

您可以重写它并告诉 WPF 如何使用 DataTemplate 绘制任何类型的对象。您可以告诉控件使用特定模板呈现，也可以告诉 WPF 使用特定 DataTemplate 自动呈现类型 X 的 UI 层中的任何对象。

所以回答你的问题

a) Do I need both, a view model locator and a DataTemplate to accomplish the above? Or more specific: Why do I have DataContext="{Binding LiveDataViewModel, Source={StaticResource Locator}}"> in my View but still need a DataTemplate?

这是两个独立的项目。 ViewModelLocator 定位 UI 对象后面的数据项，DataTemplate 告诉 WPF 如何绘制该项目。

您的绑定(bind)是说“将数据层 (DataContext) 绑定(bind)到 Locator.LiveDataViewModel”，我最好的猜测是您的 XAML 中的某些内容绑定(bind)了 ItemsSource 或 Content 直接到数据层，使用像 Content="{Binding }"

这样的 XAML

b) Is this a view model first approach or a view first approach?

我认为无论何时您使用 ViewModelLocator，它都是一种 View 优先的方法，因为 View 负责从定位器获取它的数据项。数据在 View 调用之前不存在。

就我个人而言，我从不使用 ViewModelLocator，因为我不喜欢它的限制，并且更喜欢模型优先的方法，但这并不意味着您可以根据需要使用它.

c) I tried a code behind solution and it literally took me 4 lines of code to accomplish the exact same thing that took me many classes, detours, eventToCommand & converters [because the control that triggers the choice of view only raises events not commands], data templates, view model locators, different view models...this looks like a huge cost to pay for no advantage whatsoever. Putting this into code behind seems to me perfectly fine because it is pure UI content (choose view and bind to content control, done). Am I missing something here? What would I give up via code behind?

我不知道您的代码是什么样子，但听起来好像其中有很多不必要的代码。 MVVM 模式背后的想法是让所有应用程序逻辑都驻留在类中，而所有用户界面逻辑都驻留在 UI 控件中。 WPF 由于其绑定(bind)系统而非常适合这种设计。

这使得将备用用户界面连接到您的应用程序变得容易，最常见的是测试脚本。它还具有使 UI 与业务逻辑完全分离的优势，这在与专门的 UI 团队合作时非常有帮助。

我个人对每个 WPF 应用程序都使用 MVVM，即使是非常简单的应用程序。在简单的应用程序中，我可能会稍微模糊规则，但当存在 MVVM 选项时，我永远无法回到构建应用程序的旧 WinForms 风格。

如果您有兴趣，我已经为 WPF 初学者写了一些博客文章，如果您是第一次入门，您可能会发现这些文章很有用:

• Understanding the change in mindset when switching from WinForms to WPF
• What is this "DataContext" you speak of?
• A Simple MVVM Example

希望这对您有所帮助，祝您好运:)