关于不使用 MVVM 或类似工具开发 WPF 应用程序的建议

Question

我们正在使用 WPF/Prism（复合应用程序库）。当我们即将完成与客户的合作时，我们的团队被置于新的管理之下，不久之后：

1. 然后我们被指示放弃 Prism 框架以保持事情简单。这包括不使用任何类型的控制反转。

2. 我们被指示在不使用 MVVM 或类似技术的情况下构建 WPF 应用程序；以及更多与传统 WinForm 应用程序类似的内容。这个想法是，如果开发人员在 Visual Studio 的设计器视图中看到一个控件，那么他（她）应该能够单击该控件并准确地看到它在做什么，而无需遍历视图模型（或类似的模型）。

3. 我们现在的任务是使用一个主窗口构建 WPF 应用程序，使用 框架控件 来包含内容，并使用框架外部的功能区作为菜单项。我们被允许使用帧控制的原因：

   a.我们将在框架中显示一个带有 页面（不是用户控件），然后在框架中加载该页面。

   b.当要在 Frame 中显示新视图时，当前视图（Page）将被关闭/处置，新视图（Page）将在 Frame 中取代其位置。

   c.当开发人员在设计视图中查看页面时，他（她）将能够单击任何控件并准确查看正在执行的操作。

鉴于上述 1 和 2 的限制，我们希望提出另一种构建应用程序的方法：

1. 可以作为使用“框架方法”（上面第 3 项）的替代方案，但仍然提供相同的功能 。

2. 不使用 MVVM（请参阅上面的 #1 和 #2）。

根据给定的方向，我们可以提出替代方案吗？我要求您的回复保持专业水平，并提前感谢您。

Answer 1

我个人会尝试主张使用 Martin Fowler 的演示模型。 （顺便说一句，这是个笑话...）

基本上，您受到的限制是“使用 WPF，但不要使用任何使 WPF 可用的功能”。听起来您的要求确实如此，因此您最好合理地解释 MVVM 等模式的优点。

听起来奇怪的要求实际上可以归结为：

这个想法是，如果开发人员在 Visual Studio 的设计器视图中看到一个控件，那么他（她）应该能够单击该控件并准确地看到它在做什么

如果这是主要问题，以及您避免使用 MVVM 和其他类似的模式，我会认真花时间教育管理层。按名称查看命令，而不是按名称查看事件（这是您在设计器中看到的）实际上并不困难。

然而，在大规模应用程序中，关注点分离是关键。即使正确设计的 Windows 窗体应用程序也需要完全分离关注点 - 但对于基于事件的编程，这变得更加困难，尤其是对于设计者而言。如果您尝试使用事件方法开发大规模、干净的应用程序，您将拥有事件处理程序，但这些事件处理程序最终都需要将其工作委托给单独的组件。

从可理解性和维护的角度来看，这实际上是在 MVVM 的基础上增加了额外的工作量。使用 MVVM，您只需查看 ViewModel，这是非常容易发现的。

---

顺便说一句 - 使用页面而不是用户控件的“理由”没有任何意义。您可以执行与 UserControls 描述的完全相同的操作...使用框架和页面的唯一原因是如果您想利用导航，在这种情况下，您不能直接处理旧页面（或它们不断地再生）。此外，导航工具可能不会与功能区一起使用 - 这两个概念模型完全不同。

Answer 2

有一些对 MVVM 的批评可能适用于你的项目；然而，对编程方法的不合理规定总是会导致灾难。

我们拥有框架并花时间构建层和分离的原因之一是为了避免当您可以“只需单击 Visual Studio 中的按钮即可查看正在执行的代码”时总是会导致编码混乱。

如果没有类似于 MVVM 的东西，可能就没有办法实现您被要求做的事情，因为任何具有架构的东西都可能被标记为过于相似。

然而，我多年来一直使用一个系统，该系统提供简单的对象间管道，当前称为 Emesary，您可能想阅读我的 C# .NET Emesary 演练。

但基本上它允许我的按钮这样实现：

    private void addButton_Click(object sender, RoutedEventArgs e)
    {
        GlobalTransmitter.NotifyAll(new Notification(NotificationType.CreateRecipe));
    }

这可能是您问题的答案。它没有被大肆宣传，很小，而且很简单，但效果很好。

我通过使用窗口、功能区栏的用户控件（用户控件包含列表视图）以及框架部分的另一个用户控件，实现了第二个问题的解决方案。显然，第二个用户控件是使用其他用户控件使用非常简单的视图类构建的。所有视图和控件均使用 Emesary 连接。

Answer 3

作为一个学校项目，我必须开发一个 WPF 客户端，允许多人同时使用它。我使用了 Pages。我的结论是：为自己节省大量精力，而使用 UserControls。

有时，页面导航器（您将用来滚动浏览）往往会出现错误并给您带来很多问题。也许这是我糟糕的编码，但谁知道呢？

尽管我必须说，称为“页面”的控件有些误导......我“尤里卡！”当我找到他们时，我就咒骂他们。

我完全同意#2（MS 大佬们注意了！）。如果您可以双击一个控件，它会直接带您到它的命令（如果缺少它的命令，则为事件），那就太酷了。但在此之前，请确保将视图和视图模型组织在单独的文件夹中。

拥有双屏幕（或非常宽的屏幕）将允许您在项目上打开两个 VS 实例，一个专注于视图，另一个专注于 ViewModel（我个人的选择是在视图上使用 Expression Blend）。

虽然不是一个非常大的应用程序，但我设法在几天内将我的项目转换为正确的 MVVM（即每个 UI 元素的 ViewModel、RelayCommands 和 Mediator），所以一旦你理解了它，就不会太难了实施起来很复杂。另外，还有一些工具（例如 Josh Smith 的 RelayCommand 和 Marlon Grech 的 Mediator - 完全免费）可以使 MVVM 的难度降低一半，功能强大一倍。

在没有 MVVM 的情况下使用 WPF 就像尝试没有叉子吃米饭一样。如果您不打算利用 WPF 提供的功能，那么最好使用 WinForms。我的2分钱。

Answer 4

我希望我能说你的管理是完全错误的..但我不能这么说，因为这不是最准确的事实。我猜你所描述的变化的主要原因要么是因为新经理对 MVVM 作为 UI 开发的新救世主的概念感到不舒服，要么/和另一个原因可能是受过教育的成熟开发人员与廉价开发人员的成本，可以被指示尽快完成工作，这一概念被广泛称为精益开发。

因此，将我迄今为止写的所有内容放在“不是您要求的”下，这就是我的建议：
您仍然可以使用面向对象的纯方法，这意味着您可以拥有一个已经具有显示 UI 信息的方法的模型对象。所以每个对象都将是一个窗口派生对象，这样你就会失去 SOC，但你仍然会是 OOP/OOD。

但是哈哈，下一阶段将使您将模型与视图分离，以便不在许多依赖相同数据的派生窗口中重复相同的代码...因此您的管理层将认可 MVC/MVP 作为良好的解决方案...并且如果他们想要 WPF，那么从它到 MVVM 的距离有点短。

结论：你必须告诉你的经理为什么最好选择 MVVM，除非项目非常短。