0

在此处输入图像描述

大家好

目前我有以下参考结构：

DSFinalProject 有"DAL"项目和"DataStructure"项目的参考。

DataStructure也有DAL项目的参考……</p>

现在我希望它DSFinalProject不会引用该DAL层，但能够使用该类的接口。

有什么方法可以"tunnel"将 DAL 项目中的接口连接到 DSFinalProject 而不实际在它们之间进行引用？

也许使用 DataStructure 项目？还是别的什么？

在此先感谢您的帮助:)

4

3 回答 3

1

我不知道在没有引用项目（或程序集）的情况下从 DSFinalProject 引用 DAL 项目中的接口（或其他任何东西）的任何方法。

如果您认为它使依赖项更清晰，您可以将它们移动到另一个项目 - 如果您将接口放在 DataStructure 项目中 - 您会遇到循环引用，它需要 DAL 而 DAL 需要它。

于 2012-09-21T13:05:23.730 回答
1

最简单的方法是将它们放入 中DataStructure，这还不错，因为任何引用接口的东西也需要引用DataStructure。

我的投票是将它们放在那里，直到您遇到需要将接口放在单独的程序集中的场景。

于 2012-09-21T13:09:58.640 回答
1

我不相信无论如何你问什么。如果您考虑序列化对象时会发生什么，您仍然需要程序集来提供字段在数据流中的布局方式的低级结构。它需要接口中的代码说前 4 个字节是双精度，等等。

所以唯一要做的就是将你的接口移动到一个新的interfaces.dll中，它可以被所有东西引用。您将看到这种模式在许多示例中重复出现，包括 EnterpriseLibrary。

但是...您犯了一个典型的错误。你为什么要把你的代码分成这么多项目？项目确实应该被视为我们代码的运行时打包，而不是设计时间隔离机制。通过拆分成这么多程序集，您可以做三件事。

  1. 您会减慢构建系统的速度，因为编译器会做更多的工作来获取其他程序集。
  2. 您会减慢 Visual Studio 的速度，因为加载所有项目并保持它们之间的引用更加困难。我曾经研究过一个包含 140 个项目的解决方案，只需要 15 分钟就可以打开（但我总是早上喝咖啡）。
  3. 您降低了运行时性能，因为 DotNet 必须四处搜索另一个 4k dll（这是最小值，即使只有一行代码）。尝试查看融合日志或使用 SysMon 来了解这个简单的操作涉及多少工作。

看看这个例子关于如何优化代码的提示确实会看到随着您的解决方案变得更加复杂会发生什么。

与其像这样拆分它，不如使用命名空间，您仍然可以进行分隔，但不必使用这么多引用，您现在可以通过类中的 using 语句进行控制。您将轻松查看是否在设计为 DSFinalProject 层的类中使用 DAL 引用。您可以在项目下创建一个文件夹并在那里添加您的类。摆脱所有项目，仍然有一个适当的分层系统。

随着您的解决方案的增长，等到您至少有两个可执行文件，然后再开始引入项目，然后考虑运行时影响。如果您总是要加载两个程序集，请将它们合并为一个（我最近看到一些开源项目也使用 ilmerge 合并到第三方库中）。

于 2012-09-21T13:34:24.997 回答