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

Question

我们使用WPF/Prism (Composite Application Library)构建了下一个内部厚客户应用程序的版本。由于我们几乎与客户完成了，我们的团队受到了新的管理，此后不久:

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

2. 我们被指示在不使用MVVM或类似的情况下构建WPF应用程序；以及更多的沿着传统的Winform应用程序的路线。这个想法是，如果开发人员在Visual Studio的设计师 View 中看到控件，那么他应该能够单击控件，并确切地查看其在做什么，而无需穿越 View 模型(或类似)。

3. 现在，我们已任命使用一个主窗口来构建WPF应用程序，使用Frame Control来包含内容，并在菜单项外部使用框架外的功能区。我们提供了使用帧控制的原因:

   a。我们将使用Page(而不是用户控件)在框架中显示 View ，然后将页面加载到框架中。

   b。当将新 View 显示在框架中时，当前 View (页面)将被关闭/处置，新 View (页面)将位于框架中。

   c。当开发人员查看设计 View 中的页面时，他将能够单击任何控件并确切查看正在完成的操作。

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

1. 可以作为使用“帧方法”(上面的第3项)的替代方案，但仍然提供相同类型的功能。

2. 不使用MVVM(请参见上面的＃1和＃2)。

提供了我们得到的方向，关于我们可以提出的替代方案的任何建议？我要求将答复保持在专业层面上，并提前感谢您。

Answer 1

我亲自尝试使用马丁·福勒的演示模型。 (这是个玩笑，顺便说一句...)

基本上，您得到了一个限制，上面写着“使用WPF，但不要使用使WPF可用的任何功能。”听起来您的要求确实如此，您会更好地解释MVVM等模式的优势。

。

听起来很奇怪的要求确实归结为:

The idea is that if a developer sees a control in Visual Studio’s designer view, then (s)he should be able to click on the control and see exactly what it's doing

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

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

这实际上是从可理解的和维护的角度增加了额外的努力，除了您使用MVVM的 yield 之外。使用MVVM，您只能查看ViewModel，这是非常可发现的。

---

btw-使用页面而不是UserControl的“理性”没有任何意义。您可以使用UserControls进行完全相同的事情...使用帧和页面的唯一原因是，如果您想利用导航，在这种情况下，您不能直接处理旧页面(或他们不断再生)。另外，导航工具可能不会与功能区一起使用 - 两个概念模型完全不同。