谁应该创建UI元素

我已经看到了一些不同的方法。有趣的是，所有的模式在纸上看起来都很完美，但实现细节却表明它并没有那么简单。我将以MVW(模型-视图-诸如此类)的形式给出示例，因为它在任何模式中都应该是相似的。

选项1:绑定到一个属性。这在WinForms中有点困难，但在WPF中效果很好。让你的按钮在你的演示器/控制器/视图模型上设置bool属性。然后视图根据这个值显示或隐藏它的UI。UI可以覆盖所有现有的UI，使其具有模态的外观。

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

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

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