问Winforms和WPF中复杂GUI库设计的模型-视图-演示器(或调用GUI体系结构)

EN

我不太清楚如何命名这个问题，甚至问它真的，但我会尽我所能。

我正在构建一个图表/流程图样式设计器，它涉及(从一个非常高的层次)一个工具箱的控件，连接，连接点，覆盖编辑，等等。

控件由业务对象或组件支持。(也就是说，可能有一个“Account”组件，它由一个“Account”UI/View组件表示。

下面是我上面提到的例子。

​

​

这并没有失去控制，而且应用程序也有类似的功能。

我已经有了这个(或多或少)的工作版本，但是我自己做得非常糟糕(我认为)，为了使这个可扩展，以便我可以继续我们水平地开发它(额外的工具箱支持)，我需要重构和做这个清洁剂。

我一直在参考一些关于通用GUI架构的文章，如MVP、MVVM、MP、PV、PM等。

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

我已经找到了一些关于这个主题的“最佳实践”的文章，但是对于我来说，这并不是什么可以继续的。

到目前为止，MVP是我所想象的最接近这一目标的球员，但我只是没有足够的信心去走这条路。

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

• 控件(由业务对象支持，很可能只是对稍后要创建的Type的引用)可以从工具箱拖到设计器画布上。
  • 控件可以被拖动、移除并修改其状态(业务状态)。
  • 可以在源组件和目标组件之间启动连接。
  • 连接可以被移动(两端)在一个杂乱和目标组件之间。
  • 可以打开多个设计器窗口，因此我们必须维护“活动”设计器的概念。

​

在设计这种情况时，我仍然不确定，在这种情况下，我希望维护UI状态/逻辑以及业务状态/逻辑。此外，“主动设计师”的概念会在哪里得到维护，等等。

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

我对应用于UI设计的不同模式有一定的了解，但对于复杂UI组件的库设计，它们似乎不够通用。我在这方面可能错了。我想知道的是，在这种特殊情况下，从上面讨论过的情况来看，我假设沿着MVP的路线走可能无法解释复杂的UI逻辑，这是错误的吗？