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

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

来源

2011-01-10 Keith

是的，这是糟糕的设计。你的班级应该提供一种与表单沟通的意思，并获取数据。只需创建事件并让Form订阅它们，获取信息以从定制的EventArgs类创建对话框。获得输入后，只需通过第二个事件将相同的类与附加信息一起推回。

这应该类似于MVP模式。

来源

2011-01-10 21:32:19 Femaref

MVP模式我相信，不是吗？ – nick 2011-01-10 21:59:52

这是我第一次做什么的倾向。我想我只是在寻找某人来验证它。谢谢。 – Keith 2011-01-10 23:22:53

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

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

来源

2011-01-10 21:31:59 driis

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

来源

2011-01-10 21:32:20

是的。因为这意味着你的商业对象根本就不是一个商业对象。

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

来源

2011-01-10 21:33:57 TomTom

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

来源

2011-01-10 21:54:24

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

回答

相关问题