让业务逻辑对象提示用户输入是不好的设计吗？答案

【问题标题】：Is it bad design to have a business logic object prompt the user for input?让业务逻辑对象提示用户输入是不好的设计吗？
【发布时间】：2011-01-10 21:29:06
【问题描述】：

我有一个正在实现的流程图，它有 4 或 5 条路径通过它，具体取决于用户输入和某些处理的结果。自然，我不想在我的 Windows 窗体中使用所有这些逻辑，我只想在窗体中的类上调用一个方法。让我的业务逻辑类引用 System.Windows.Forms 并显示对话框和 MessageBoxes 来获取它需要处理并返回结果的输入是不是糟糕的设计？

【问题讨论】：

标签： c# .net oop design-patterns

【解决方案1】：

是的，这是糟糕的设计。您的课程应该提供一种与表单进行通信并取回数据的方法。只需创建事件并让Form 订阅它们，从自定义EventArgs 类获取创建对话框的信息。在它获得输入后，只需通过第二个事件将带有附加信息的同一个类推回即可。

这应该类似于 MVP 模式。

【讨论】：

我相信的 MVP 模式，不是吗？
这是我的第一个想法。我想我只是在找人来验证它。谢谢。
是的，这应该是真的，尼克。但是，我认为这个例子更合适，不过我应该提到它。

【解决方案2】：

是的，这是个坏主意。您正在有效地将业务逻辑与演示文稿非常紧密地耦合在一起。您（可能不会）能够在其他情况下轻松重用业务逻辑，并且您将无法在不触及业务逻辑的情况下更换 UI。

您需要让 UI 和业务逻辑层进行通信，并让 UI 层处理 UI。

【讨论】：

【解决方案3】：

我认为这是糟糕的设计。当您分离应用程序的组件时，经验法则是使它们保持足够的分离，以便您可以在不同的计算机上运行它们。

【讨论】：

【解决方案4】：

是的。因为这意味着您的业务对象根本不是业务对象。

使用 MVVM 模式并将逻辑放入视图模型中。

【讨论】：

我怀疑 MVC 更适合 WinForms，尽管我猜所使用的确切模式不如使用经过严格审查的模式相关。
我认为基于事件的 MVP 模式也是一种选择。视图触发事件，演示者以神奇、神秘的方式处理它们。

【解决方案5】：

这是一个糟糕的设计，因为您可能需要在具有不同 UI 或根本没有 UI 的情况下（例如在服务器或批处理中）运行业务逻辑。这就是业务逻辑和 UI 分离的意义所在。如果可能，最好先在 UI 类中获取所有必要的用户输入，然后再将其交给业务逻辑。但是，如果需要让业务逻辑提示更多信息，那么业务逻辑 API 最好采用回调方法委托，它可以调用该委托来请求进一步的输入。然后 UI 层可以决定如何最好地向用户请求。

【讨论】：