c# - 不断增长的 .NET 项目的管理和结构

Question

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

该应用程序由一个 GUI (WinForms) 组件和动态加载到其中以供执行的各种“操作”组成。

大约有 100 个行动项目已经在进行中，而且这个数字还在增加。其中一些项目与其他项目相互依赖等等。

加载的所有操作都必须引用我们的“SDK”dll 以进行各种事件(主应用程序的结果、日志记录等)。

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

1. 操作(“插件”)应该引用我们的 SDK 项目输出，还是它的某个已知稳定版本？例如，在开发大型应用程序(仅以 MS Office 为例)时，并非所有团队都自然地使用所有组件的源代码。

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

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

在管理相互关联的多个项目的场景中，常见做法是什么？这样做有什么技巧吗？

Answer 1

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

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

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

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

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

松散耦合的系统使用 MEF(托管可扩展性框架)等框架，您的组件引用定义组件接口(interface)的“Contract DLL”。项目引用接口(interface)或契约(Contract) DLL，并不真正关心实现，然后 MEF 为您管理插件。

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

例如，假设我有一个名为 ILog 的接口(interface)和一个名为 LogMessage 的方法。

private ILog _logger;
_logger.LogMessage();

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

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

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

您选择的方式，无论哪种方式都是可以接受的，我认为松散耦合的想法最适合您的场景，因为团队只需要了解契约(Contract)与实际实现。

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