我目前有一个项目是“业务对象”项目，我们的目标是在GUI和业务对象之间有明确的分离。但是，我的项目有System.Windows.Forms的参考，这对我的项目设计不佳的每个人来说都是一个大红旗。如何让'GUI'层保留'业务逻辑'层？
我的问题是，我正在使用称为“活动查询生成器”的第三方控件。这实际上是一个'控制'，如在GUI中，System.Windows.Forms.Control;但它永远不会显示在任何地方，并添加到任何窗体控件集合中。它提供了业务对象的许多核心功能。
无论如何，没有引用System.Windows.Forms - 我不能使用第三方控件和BO是可怕的破碎。但我被告知我不能引用System.Windows.Forms，因为它是不好的编码习惯。
而我完全丧失了做什么。
具有更多设计模式类型体验的人可以提供解决方案吗？
因此，您有一个引用WindowsForms的库，但不直接使用任何东西？你的BO项目没有搞乱任何形式？
我认为你很好，那么参考是一个红旗，说等待为什么我这样做。但只要该层仍然逻辑分离，那么恕我直之，你的确定。
你可以做的一件事是将这个抽象出来，以处理与查询生成器交互的另一个项目。因此，您的BO项目将与知道如何使用此控件的查询生成器项目一起工作。
我在这里可能是错的，但System.Windows.Forms只是.NET框架的一部分，实际上并不构成GUI。它可能有许多有用的功能，你可能会利用它们不显示任何东西。我认为无论谁说这不应该被使用可能会误解这个原则。
如果您正在开发一个n层应用程序，那么操作GUI-Business Logic-Data Store是很常见的，但GUI仅限于提供给用户允许交互的用户界面，而不是促进它的框架。
我只是模糊地熟悉Active Query Builder，但是不是用于创建SQL查询的GUI组件吗？我不知道这种组件属于商业对象。
我对它并不熟悉，但如果它允许在设计时构建查询，然后需要该组件在运行时执行，那么它包含在内并且它使用表单是有意义的。 – Lazarus 2009-04-22 15:35:18
除了GUI控件，它提供了生成SQL的能力，并且通常会做一些非常酷的事情。从本质上讲，我有一堆“标准”，并希望返回匹配的数据或获得这些匹配所需的SQL。AQB控制是其核心 - 但我们已经建立了相当多的目标，并希望其他BO利用该功能。 – 2009-04-22 15:51:09
（我不确定这是否证明它是在BO中 - 也许它不应该在那里） – 2009-04-22 15:51:47
您可以为控件创建一个包装类，该类使用您需要的方法实现接口。您的业务对象可以依赖于该接口，可以由任何东西实现（在这种情况下，它是一个控件）。
它确实引起一些担心，即这个“控件”具有与UI无关的功能;它只是感觉不对。
这很有道理 - 谢谢。如果你知道的话， – 2009-04-22 15:34:25
很想听听我为什么得到-1。我很想听听你的意见。 – JoshBerke 2009-04-22 16:10:48