3

我们正在使用WPF/Prism（复合应用程序库）构建下一个版本的内部胖客户端应用程序。由于我们几乎完成了与客户的合作，我们的团队被置于新的管理之下，此后不久：

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

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

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

    一种。我们将在 Frame 中显示一个带有Page（不是用户控件）的视图，然后在 Frame 中加载该页面。

    湾。当要在框架中显示新视图时，当前视图（页面）将被关闭/处置，新视图（页面）将在框架中取而代之。

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

鉴于上述 1 和 2 的限制，我们想介绍另一种构建应用程序的方法：

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

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

如果我们得到了指导，关于我们可以提出的替代方案有什么建议吗？我要求将回复保持在专业水平，并提前感谢您。

4

4 回答 4

6

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

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

听起来奇怪的要求真的归结为：

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

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

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

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

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

于 2010-03-17T01:01:40.293 回答
2

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

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

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

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

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

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

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

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

于 2010-03-17T01:58:04.657 回答
1

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

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

虽然我必须说，被称为“页面”的控件有点误导......我去了“尤里卡！” 当我找到他们的时候，然后对他们发誓。

我完全同意＃2（MS大人物请注意！）。如果你可以双击一个控件，它会直接带你到它的命令（如果缺少它的命令，或者事件），那将是很酷的。但是在此之前，请确保将视图和视图模型组织在单独的文件夹中。

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

虽然不是一个非常大的应用程序，但我设法在几天内将我的项目转换为适当的MVVM（即每个 UI 元素、RelayCommands 和 Mediator 的 ViewModel），所以一旦你理解了它，实现起来并不太复杂。此外，还有一些工具（例如 Josh Smith 的 RelayCommand 和 Marlon Grech 的 Mediator——顺便说一句，完全免费）使 MVVM 的难度降低了一半，而功能则提高了两倍。

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

于 2010-05-18T16:51:18.010 回答
0

我希望我能说你的管理是完全错误的。但我不能这么说，因为这不是最准确的事实。我想您所描述的更改的主要原因是因为新经理对 MVVM 作为 UI 开发的新救世主的概念不满意，或者/和另一个原因可能是受过教育的老练开发人员与廉价开发人员的成本。可以指示尽快完成工作，这一概念被广泛称为精益开发。

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

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

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

于 2012-06-12T16:33:04.877 回答