用于Winforms和WPF中的复杂GUI库设计的Model-View-Presenter（或其他GUI架构）

Question

我不太确定如何标题这个问题，甚至不会问它，但我会尽我所能。

我正在构建一个图表/流程图样式设计器，它涉及（从很高的层次）控件，连接，连接点，编辑叠加等工具箱。

控件由业务对象或组件支持。 （即可能有一个＆＃39; Accounts＆＃39;组件，由＆＃39; Accounts＆＃39; UI / View组件代表。

以下是我上面提到的示例模型。

这不是失控的，应用程序的hundres具有类似的功能。

我已经有了这个（或多或少）的工作版本，但是我自己（在我看来）做得非常差，并且为了让我们能够实现这种可扩展性以便我可以继续开发它是我们的横向（额外的工具箱支持），我需要重构并做到更清洁。

我一直在引用一些关于常见GUI架构的文章，如MVP，MVVM，MP，PV，PM等。

我担心的是，到目前为止我所阅读的内容与为CRUD操作定义GUI架构密切相关。这些都不是真正讨论复杂的UI库设计。

我能找到一些文章，提供一些最佳实践＆＃39;关于这个话题，但对我来说真的不多了。

到目前为止，MVP最接近我的想象，但是我不太相信它会走这条路。

这可能没多大帮助，但我想我可以列出一些需要考虑的交互/行为。没有什么与您在图表或流程图应用程序中看到的不同。

• 控件（由业务对象支持，很可能只是对稍后要创建的类型的引用）可以从工具箱拖动到设计器画布。
  • 可以拖动，删除控件并修改其状态（业务状态）。
  • 可以在源组件和目标组件之间启动连接。
  • 可以在soruce和目标组件之间移动连接（两端）。
  • 可以打开多个设计师窗口，因此我们必须保持“活跃”的概念。设计师。

我仍然不确定在设计这个我希望维护UI状态/逻辑以及业务状态/逻辑的地方。此外，“活跃设计师”的概念在哪里？保持等等。

更新显然，这是SO巨魔的另一个目标，所以我会尝试澄清我的问题/帖子。

我对应用于UI设计的不同模式有点了解，但是对于复杂UI组件的库设计而言，它似乎不够通用。我可能错了。我想知道的是在这个特定场景的情况下，从上面讨论的内容来看，我错误地认为沿着MVP的路线走下去可能无法解释复杂的UI逻辑吗？

Answer 1

此级别的所有模式（MVP，MVVM等）都适合您需要的任何复杂性。它能够处理的只取决于你，你必须理解它仍然只是一种模式，而不是一个你必须使用的预制函数的框架。

无论你做什么，都可以在Winforms上选择WPF，特别是当你需要对UI进行复杂的控制时。