c# - 谁应该创建 UI 元素？

Question

我有一个使用 MVP 的 WinForms 应用程序，但我不完全确定如何处理需要创建新 UI 元素的场景。

例如，假设我的视图有一个按钮，该按钮应该以对话框的形式打开一个新视图（表单）。视图或演示者应该创建新视图还是演示者的工作？

这是我的思考过程：

1. 视图应将其创建为 UI 特定操作。但...
2. 演示者应该这样做，因为视图应该是被动的。但是演示者不应该知道 UI 的细节。

解决这个问题的正确方法是什么？

Answer 1

我已经看到这有几种不同的方式。有趣的是，所有模式在纸上看起来都很完美，然后实现细节表明它并不那么简单。我将以 MVW（模型-视图-whatever）的形式给出示例，因为它在任何模式下都应该是相似的。

选项 1：绑定到属性。这在 WinForms 中有点困难，但在 WPF 中效果很好。让您的按钮在您的演示者/控制器/视图模型上设置一个布尔属性。然后，您的视图会根据此值简单地显示或隐藏它的 UI。UI 可以覆盖所有现有的 UI 以具有模式的外观。

选项 2：服务。引入一个 DialogService（希望您设置了依赖注入，因此添加起来很简单）。该服务有一个 ShowDialog(options) 方法。选项可以是标题、消息、命令（带有按钮的标题和操作）。让您的按钮在演示者上设置属性或触发命令，然后调用它的 dialogService 的 ShowDialog 方法。这样，您的视图仍然只是简单地调用您的演示者并且它正在使用该服务。视图不应该知道服务。这允许您的 DialogService 构建适当的 UI，然后启动新表单。这也是我喜欢包装本机 MessageBox.Show 调用的方式，以便您可以用 DialogService 替换所有这些调用。

选项3：不要成为纯粹主义者。如果您的模式不需要与演示者交互，或者您只是想要返回基本数据（例如颜色选择器或类似的东西），那么只需让您的视图处理它。您的按钮可以简单地打开模式，模式具有发送回视图的值。然后你的视图使用它们。如果数据没有理由将其返回给演示者，请不要将事情过度复杂化以成为纯粹主义者。视图仍然可以执行基于 UI 的逻辑。我仅将视图用于许多 UI，例如使用鼠标/触摸事件移动元素或缩放计算。如果逻辑只是 UI，请将其保留在视图的代码中。如果它是重复的 UI 逻辑，请将其移至服务或用户控件或自定义视图。

在所有 MVP/MVC/MVVM 文档中，它们总是缺少关键的细节。对我来说，服务是缺失的一环。它们允许插入松散耦合的逻辑，您可以将一些丑陋的 UI 绑定或 UI 事件包装到服务中并保持整洁。

希望这可以帮助。