C# 单体仓库：.NET 项目中的代码组织

使用 C# 的单一仓库：如何在 .NET 项目中组织代码

现代 C# 和 .NET 开发越来越频繁地面临一个选择：将所有相关项目存储在一个仓库（单一仓库）中，还是将它们分散到单独的仓库（多仓库）中。单一仓库是一种将多个应用程序、库、测试和配置的代码存储在一个 Git 仓库中的方法。对于大型企业解决方案、微服务或 NuGet 库，这种方法可以显著简化依赖管理、重构和部署。

在本文中，我们将探讨如何在 .NET 生态系统中正确组织一个使用 C# 的单一仓库，包括文件夹结构、项目配置、CI/CD 和最佳实践。

1. .NET 中单一仓库的优缺点

在深入技术细节之前，了解单一仓库何时真正有用，以及何时可能成为问题，这一点很重要。

优点：

• 统一的依赖版本。 仓库内的所有项目使用相同版本的包，从而避免版本冲突。
• 简化的重构。 更改公共接口或库的 API 会立即在所有使用它的项目中体现出来。
• 提交的完整性。 同时更改库和应用程序的原子性提交可以无缝工作，没有时间差。
• 共享配置。 一个 Directory.Build.props 文件为所有项目设置编译、代码分析和版本设置。

缺点：

• 仓库大小增长。 随着时间的推移，克隆和历史记录可能会变得非常大。
• CI/CD 复杂性。 需要一个智能的构建系统，以避免在每次提交时重新构建所有内容。
• 访问权限。 在单个仓库中，为不同团队划分访问权限更加困难。

对于 .NET 项目，当您有一个共享的类库（例如 Domain 或 Common）以及多个依赖它的微服务或 Web API 时，单一仓库尤其方便。

2. 用于 C# (.NET) 的单一仓库结构

正确的文件夹结构是成功单一仓库的基础。让我们考虑一个包含多个微服务、一个库和测试的解决方案的典型组织方式。

MyApp/├── .github/│   └── workflows/│       └── ci.yml├── src/│   ├── MyApp.Common/          # 共享库│   │   ├── MyApp.Common.csproj│   │   └── ...│   ├── MyApp.Api.Orders/      # 订单微服务│   │   ├── MyApp.Api.Orders.csproj│   │   └── ...│   └── MyApp.Api.Users/       # 用户微服务│       ├── MyApp.Api.Users.csproj│       └── ...├── tests/│   ├── MyApp.Common.Tests/│   │   ├── MyApp.Common.Tests.csproj│   │   └── ...│   └── MyApp.Api.Orders.Tests/│       ├── MyApp.Api.Orders.Tests.csproj│       └── ...├── Directory.Build.props       # 所有项目的共享设置├── MyApp.sln                   # Visual Studio 解决方案文件└── README.md

关键点：

• 所有项目都位于 src/ 文件夹中，测试位于 tests/ 中。这是 .NET 社区采用的标准。
• Directory.Build.props 文件设置共享属性：TargetFramework、Nullable、ImplicitUsings、包版本等。
• 一个 SLN 文件简化了在 IDE 中的工作，但如果项目数量很多，可以将其拆分为多个解决方案。

Directory.Build.props 示例：

<Project>  <PropertyGroup>    <TargetFramework>net8.0</TargetFramework>    <Nullable>enable</Nullable>    <ImplicitUsings>enable</ImplicitUsings>    <TreatW