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

Question

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

Answer 1

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

这应该类似于MVP模式。

Answer 2

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

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

Answer 3

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

Answer 4

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

使用MVVM模式并将逻辑放入viewmodel。

Answer 5

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