4

我目前有一个项目是“业务对象”项目，我们的目标是在 GUI 和业务对象之间有一个明确的分离。但是，我的项目引用了System.Windows.Forms，这对每个人来说都是一个很大的危险信号，即我的项目设计不佳。

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

无论如何，如果没有对 System.Windows.Forms 的引用 - 我不能使用第 3 方控件并且 BO 被严重破坏了。但有人告诉我，我不能引用 System.Windows.Forms，因为这是不好的编码习惯。

我完全不知道该怎么做。

具有更多设计模式类型经验的人可以提供解决方案吗？

4

4 回答 4

6

所以你有一个引用 WindowsForms 的库，但不直接使用任何东西？您的 BO 项目没有弄乱任何表格？

我认为你很好，参考是一面红旗，上面写着等等我为什么要这样做。但是只要该层在逻辑上仍然是分开的，那么恕我直言，你可以。

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

于 2009-04-22T15:32:35.077 回答
3

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

如果您正在开发 n 层应用程序，通常会操作 GUI-业务逻辑-数据存储分离，但 GUI 严格来说是呈现给用户以允许交互的用户界面，而不是促进交互的框架。

于 2009-04-22T15:33:12.453 回答
2

我只是模糊地熟悉 Active Query Builder，但这不是用于创建 SQL 查询的 GUI 组件吗？我完全不知道这种组件是如何属于业务对象的。

于 2009-04-22T15:34:05.447 回答
1

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

它确实引起了一些担忧，即这个“控件”具有与 UI 无关的功能；只是感觉不对。

于 2009-04-22T15:34:11.420 回答