.net - 如何将一个巨大的解决方案分成更小的部分

Question

在我的日常工作解决方案中，我们大约有 80 个项目。该解决方案包含 4 个不同的网站、业务逻辑和基础设施组件(例如扩展方法、各种实用程序、存储库基类等)。

该解决方案效果很好，但是如果我们将测试项目添加到解决方案中，我们很容易通过 100 多个项目，这使得使用该解决方案非常乏味。

在我寻找解决方案的过程中，我对 Nuget 非常感兴趣，我开始想知道它是否可以帮助我们。

想法是将庞大的解决方案拆分为更小的原子片段，其输出将是一个 Nuget 包，以上传到私有(private) Nuget 存储库。

网站将引用绑定(bind)到该特定网站的类库以外的包。

从 CI 的角度来看:

每个包解决方案都应该是原子的。

它应该能够获取它的引用(其他 NuGet 包，来自官方提要和私有(private)提要)；

构建

运行它的测试

组装包

将新包上传到存储库

产品解决方案(比如网站)应该在以下之后构建:

提交他们的代码

私有(private)存储库上的 NuGet 包更新

有什么建议吗？或者也许是一种更好的方法来实现这个巨大的解决方案的 split ？

Answer 1

使用包管理(在 Windows 上:NuGet)当然是一种可靠的方法。您“免费”获得依赖解析，并且可以利用 semantic versioning仅通过包版本号将有意义的信息传达给包消费者。

但是，NuGet 实际上是一些更基本模式的特定实现:

仅构建已更改的代码

将系统分解为可管理的小单元

不要构建“框架”

从您的问题来看，听起来您正在构建比必要更多的代码，并且您的代码的模块化程度低于应有的程度。使用 NuGet 模块化您的代码将有助于实现这三种模式(当然是 1 和 2 - 您需要为 3 采取额外的步骤)。

应用这些模式也将有助于@Fede(对于谁 - 使用 C 和 C++ 代码 - NuGet 不适用)。通常，通过使您的软件更加模块化(但避免构建一个单一的、无所不知的“框架”，通常称为 *.Library.dll 或 *.Common.dll 等)，您将实现 better build architecture .

最终，每个“ block ”代码(Visual Studio 术语中的项目或解决方案)都应该为单个开发人员所理解；如果它太笨重或复杂，请将其拆分。项目、解决方案、.cs 文件等都是 人类抽象 ，而不是机器，所以它们的大小和它们之间的关系应该反射(reflect)我们人类的能力和理解的需要。采取太 far 将导致需要更改多个包以完成单个功能:在这种情况下，定义上的分离是细粒度的，您需要再次将一些代码重新组合在一起。

(披露:我是 Windows Package Management - PackageManagementBook.com 的合著者)