【发布时间】：2014-09-06 16:37:13
【问题描述】：
我不太确定如何为这个问题命名，甚至问这个问题，但我会尽力而为。
我正在构建一个图表/流程图样式设计器，其中涉及（从非常高的级别）控件、连接、连接点、用于编辑的覆盖等的工具箱。
控件由业务对象或组件支持。 （即，可能有一个由“Accounts”UI/View 组件表示的“Accounts”组件。
下面是我上面提到的样机模型。
这不是失控的，数百个应用程序都有类似的功能。
我已经有一个工作版本（或多或少），但我自己做得很糟糕（在我看来），为了让我们能够使其可扩展，以便我可以继续开发它是我们的水平（额外的工具箱支持），我需要重构并做到这一点。
我一直在参考一些关于常见 GUI 架构的文章，例如 MVP、MVVM、MP、PV、PM 等。
我担心的是，到目前为止，我所阅读的所有内容都与为 CRUD 操作定义 GUI 架构密切相关。这些都没有真正讨论复杂的 UI 库设计。
我已经找到了几篇关于这个主题的“最佳实践”的文章，但对我来说真的没有多少可以继续下去了。
到目前为止，MVP 是最接近我想象的可行方案，但我只是没有足够的信心走这条路。
这可能没有多大帮助，但我想我可以简要列出一些需要考虑的交互/行为。与您在图表或流程图应用程序中看到的不同。
- 控件（由业务对象支持，很可能只是对稍后要创建的类型的引用）可以从工具箱拖到设计器画布上。
- 可以拖动、移除控件并修改其状态（业务状态）。
- 可以在源组件和目标组件之间启动连接。
- 可以在源组件和目标组件之间（在两端）移动连接。
- 可以打开多个设计器窗口，因此我们必须保持“活跃”设计器的概念。
我仍然不确定在设计这个的情况下我想要维护 UI 状态/逻辑以及业务状态/逻辑。此外，“活跃设计师”的概念将在哪里保持等。
更新显然，这是 SO 巨魔的另一个目标，所以我将尝试澄清我的问题/帖子。
我对应用于 UI 设计的不同模式有所了解，但是对于复杂 UI 组件的库设计来说，它们似乎不够通用。我可能是错的。我想知道的是，在这种特殊情况下，从上面讨论的内容来看，我假设沿着 MVP 的路线可能无法解释复杂的 UI 逻辑是否是错误的？
【问题讨论】：
-
您在这里注册快 5 年了，您还问这样的问题吗？没有“最佳解决方案”。如何设计软件架构取决于您，我们无法为您决定。每个人都会推荐他的方法，但这根本不适合。没有明确的答案，这太自以为是了。
-
模式将取决于您的目标平台：对于 WPF 毫无疑问这是 MVVM，对于 WinForms AFAIK MVP 是参考模式。如果您使用 WPF：来帮助您构建您的应用程序，您有 Prism 但我担心这在您的情况下是多余的，并且为了简化 MVVM 开发，您有专门的框架，例如 MVVM Light 和 Caliburn Micro。
-
@walther 如果我似乎在寻求“最佳解决方案”，我深表歉意，尽管我不记得在我的帖子中提到过这些话。我想了解的是，这些常见的 UI 模式是否能够处理复杂的 UI 交互，或者它们是否通常是可能不够充分的高级抽象模式。