Question

我们正在使用WPF/Prism (Composite Application Library)构建下一版本的内部胖客户端应用程序。当我们与客户差不多完成时，我们的团队被置于新的管理层之后不久：

然后我们被指示放弃Prism框架以保持简单。这包括不使用任何类型的控制反转。
我们被指示在不使用MVVM或类似的情况下构建WPF应用程序;以及更传统的WinForm应用程序。这个想法是，如果开发人员在Visual Studio的设计器视图中看到一个控件，那么他应该能够点击控件并确切地看到它正在做什么，而不必遍历视图模型（或类似）。
我们现在的任务是使用一个主窗口构建WPF应用程序，使用Frame Control包含内容，并在框架外使用功能区作为菜单项。我们被提供使用帧控制的原因：

一个。我们将使用Page（不是用户控件）在框架中显示视图，然后在框架中加载页面。

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

℃。当开发人员在设计视图中查看页面时，他将能够点击任何控件并查看正在完成的操作。

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

可以作为使用“框架方法”（上面第3项）的替代方案，但仍然提供相同类型的功能。
不使用MVVM（参见上面的＃1和＃2）。

如果我们已经给出了指示，我们可以提出任何替代方案的建议吗？我要求将答复保持在专业水平，并提前感谢你。

Answer 1

我个人试图争论使用Martin Fowler的演示模型。（那是个玩笑，顺便说一句......）

基本上，您会受到限制，说“使用WPF，但不要使用任何使WPF可用的功能”。听起来你的要求是这样的，你可以更好地解释MVVM等模式的优势。

听起来奇怪的要求真的是沸腾到这个：

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

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

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

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

BTW - 使用Page而不是UserControl的“基本原理”没有任何意义。您可以使用UserControls执行完全相同的操作...使用框架和页面的唯一原因是，如果您想利用导航，在这种情况下，您无法直接处理旧页面（或它们不断得到再生。此外，导航工具可能不会与功能区一起使用 - 两个概念模型完全不同。

Answer 2

对MVVM的批评可能适用于您的项目;然而，对编程方法的不合理要求总是一种灾难。

我们拥有框架并花费时间构建图层和分离的原因之一是避免在“只需单击visual studio中的按钮以查看正在执行的代码”时总会产生的编码混乱。 / p>

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

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

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

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

这可能是您问题的答案。它在大肆宣传，小而简单，但它运作良好。

通过使用Window，功能区栏的用户控件（用户控件包含listview）以及Frame部件的另一个用户控件，我已经实现了第二个问题的解决方案。显而易见的第二个用户控件是使用非常简单的视图类使用其他用户控件构建的。所有视图和控件都使用Emesary连接。

Answer 3

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

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

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

我完全同意＃2（MS大人注意！）。如果你可以双击一个控制它会很酷，它将直接指向它的命令（如果缺少命令，则会发生事件）。但在此之前，请确保将视图和ViewModel组织在单独的文件夹中。

拥有双屏幕（或非常宽的屏幕）将允许您在项目中打开两个VS实例，一个围绕View而另一个围绕ViewModel（我个人选择在View上使用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。

但LOL，下一阶段将带您从视图中分离模型，以便在许多原始窗口中重复相同的代码，这些窗口继续传输相同的数据...因此您的管理层将认可MVC / MVP作为良好的解决方案..如果他们想要WPF，它与MVVM的距离有点短。

结论：除非项目很短，否则你必须教你的经理为什么最好去MVVM。

关于在不使用MVVM或类似程序的情况下开发WPF应用程序的建议

4 个答案: