用于Winforms和WPF中的复杂GUI库设计的模型 – 视图 – 展示器（或其他GUI架构）
我不太确定如何标题这个问题，甚至不确定，但我会尽我所能。
我正在构建一个图表/流程图样式设计器，它涉及（从很高的层次）控件，连接，连接点，编辑叠加等工具箱。
控件由业务对象或组件支持。 （即可能存在由’Accounts’UI / View组件表示的’Accounts’组件。
下面是我上面提到的示例模型。
这不是失控的，应用程序的hundres具有类似的function。
我已经有了这个（或多或少）的工作版本，但是我自己（在我看来）做得非常糟糕，为了让我们能够实现这种可扩展性，以便我可以继续我们的水平开发（额外的工具箱支持），我需要重构并做到更干净。
我一直在引用一些关于常见GUI架构的文章，如MVP，MVVM，MP，PV，PM等。
我担心的是，到目前为止我所阅读的所有内容都与为CRUD操作定义GUI架构密切相关。 这些都不是真正讨论复杂的UI库设计。
我已经能够找到一些文章给出了关于这个主题的一些“最佳实践”，但对我而言，这对我来说并不是很重要。
到目前为止，MVP最接近我的想象会为此工作，但我不相信足够顺其自然。
它可能没多大帮助，但我想我可以列出一些需要考虑的交互/行为。 没有什么与您在图表或流程图应用程序中看到的不同。
- 控件（由业务对象支持，很可能只是对稍后要创建的类型的引用）可以从工具箱拖动到设计器canvas。
- 可以拖动，删除控件并修改其状态（业务状态）。
- 可以在源组件和目标组件之间启动连接。
- 可以在soruce和目标组件之间移动连接（两端）。
- 多个设计师窗口可以打开，因此我们必须保持“主动”设计师的概念。
我仍然不确定在设计这个我希望维护UI状态/逻辑以及业务状态/逻辑的地方。 此外，“活跃设计师”的概念将保持在哪里等等。
更新显然，这是SO巨魔的另一个目标，因此我将尝试澄清我的问题/post。
我对应用于UI设计的不同模式有一定的了解，但是对于复杂UI组件的库设计而言，它似乎不够通用。 我可能错了。 我想知道的是在这个特定场景的情况下，从上面讨论的内容来看，我错误地认为沿着MVP的路线可能无法解释复杂的UI逻辑？
此级别的所有模式（MVP，MVVM等）都适用于您需要的任何复杂性。 它能够处理的只取决于你，你必须理解它仍然只是一个模式，而不是一个你必须使用的预制函数的框架。
无论你做什么，都可以在Winforms上选择WPF，特别是当你需要对UI进行复杂的控制时。