如何将“GUI”层保留在“业务逻辑”层之外?

时间:2009-04-22 15:28:31

标签: .net design-patterns business-objects

我目前有一个项目是“业务对象”项目,我们的目标是在GUI和Business Objects之间实现明确的分离。但是,我的项目引用了 System.Windows.Forms ,这对我的项目设计不佳的每个人来说都是一个大红旗。

我的问题是我正在使用名为“Active Query Builder”的第三方控件。它实际上是GUI中的'Control',System.Windows.Forms.Control;但它永远不会显示在任何地方,添加到任何Form的Controls集合中。它提供了业务对象的许多核心功能。

无论如何,没有对System.Windows.Forms的引用 - 我无法使用第三方控件而且BO被可怕地打破了。但是我被告知我不能引用System.Windows.Forms,因为它编码不好。

我完全不知道该做什么。

具有更多设计模式类型经验的人能否提供解决方案?

4 个答案:

答案 0 :(得分:6)

所以你有一个引用WindowsForms的库,但不直接使用任何东西?你的BO项目没有乱搞任何形式?

我认为你很好,参考是一个红旗,说等我为什么这样做。但只要该层仍然在逻辑上分离,那么恕我直言你的确定。

您可以做的一件事就是将其抽象为另一个可以处理与查询构建器交互的项目。因此,您的BO项目将与Query Builder项目一起使用,该项目将知道如何使用此控件。

答案 1 :(得分:3)

我可能在这里错了,但System.Windows.Forms只是.NET Framework的一部分,实际上并不构成GUI。它可能有许多有用的功能,您可能会使用它们不显示任何内容。我认为任何人都说不应该使用这个可能会误解这个原则。

如果您正在开发n层应用程序,则通常会运行GUI-Business Logic-Data Store分离,但GUI严格来说是用户界面,提供给用户以允许交互,而不是促进它的框架。 / p>

答案 2 :(得分:2)

我只是熟悉Active Query Builder,但它不是用于创建SQL查询的GUI组件吗?我很遗憾看到那种组件如何属于业务对象。

答案 3 :(得分:1)

您可以为控件创建一个包装类,该类使用您需要的方法实现接口。您的业​​务对象可以依赖于该接口,可以由任何东西实现(在这种情况下,它是一个控件)。

它确实引起了一些担忧,即“控制”具有与UI无关的功能;它只是感觉不对。