不断发展的.NET项目的管理和结构

Question

我们正在为我们公司内部使用的测试自动化构建一个.NET软件平台.

该应用程序由GUI(WinForms)组件和动态加载到其中以执行的各种"动作"组成.

已经有大约约100个行动项目,这个数字正在增加.其中一些项目与其他项目相互依赖,依此类推.

加载的所有操作必须引用我们的"SDK"dll用于各种活动(结果到主应用程序,记录等).

通过这种相对简单的设计,我们面临着一些我们希望以最佳方式解决的管理决策:

1. 动作("插件")应该引用我们的SDK项目输出,还是某些已知的稳定版本？例如,在开发大型应用程序(仅用于示例的MS Office)时,并非所有团队都自然地使用所有组件的源代码.

对于这样的事情,最好的解决方案是什么？为什么？

1. 如何正确验证所有需要的依赖项(例如第三方库)确实是从正确的位置获取的？

管理众多项目之间的场景中的常见做法是什么？这样做有什么提示吗？

Answer 1

这是一个没有明确答案的问题，但是......

您可以选择两条路。强耦合系统或松耦合系统。

对于强耦合系统，我可以建议两个二进制文件目录：一个第三方目录和一个包含贵公司构建的可供其他开发人员参考的 DLL 的目录。第 3 方 DLL（公司外部）应位于源代码管理中，以便所有开发人员从同一位置引用相同版本的第 3 方 DLL，从而避免开发人员计算机不一致以及在每台计算机上安装第 3 方软件的问题。内部 DLL 不应在源代码管理中引用，而应通过自动构建批处理文件或类似文件在每个开发人员计算机上构建。在构建后步骤中，您可以将它们全部复制到同一目录，只要开发人员获得最新的源代码控制和构建，每个人都可以从公司内部获得相同的 DLL。

例如，获取最新版本、构建（使用批处理文件构建所需的所有项目），然后作为构建后步骤将输出复制到 common。现在，您的所有其他项目都可以从同一位置引用通用公司 DLL 和第三方 DLL，并且每个人都是一致的。

问题在于引用是强耦合的，因此如果沟通不正确，更改有时可能会出现问题。

松散耦合的系统使用诸如 MEF（托管可扩展性框架）之类的框架和定义组件接口的组件引用“合同 DLL”。该项目引用接口或合约 DLL，并不真正关心实现，然后 MEF 会为您管理插件。

在这种情况下，您引用接口 DLL，而不是实际实现的 DLL。

例如，假设我有一个名为 ILog 的接口，其中包含一个名为 LogMessage 的方法。

private ILog _logger;
_logger.LogMessage();

因此，在强耦合情况下：Action.DLL 直接引用 Logger.DLL。

在松散耦合的情况下，Action.DLL 引用 ILog.DLL（只是接口）。Logger.DLL 实现 ILog.DLL。但Action.DLL没有直接引用Logger.DLL。

现在我可以拥有任意数量的实现 ILog 接口的 DLL，但 Action.DLL 不会直接引用它们。这非常酷，而且是 MEF 和松散耦合中更令人兴奋的功能之一，即没有依赖关系的能力。

你选择如何走，无论哪种方式都是可以接受的，我认为松散耦合的想法最适合你的场景，因为团队只需要了解合同与实际实现。

我不会有一个庞大的合约 DLL，我会尝试将接口分解为逻辑分组。例如，日志记录看起来像是一个实用程序类型的接口，因此我将创建一个带有 ILog 接口的实用程序合约 DLL。如何分割取决于您想要做什么。或者每个接口都可以是一个契约 DLL，但这也许有点极端。