Dependencies 努吉特依赖地狱

我有一个关于自己的NuGet服务器和自己的NuGet包的小问题，我们正在推动它。 我们有几个项目和一个经过调整的TFS构建过程，它将NuGet包自动推送到我们的NuGet服务器——到目前为止，它工作得非常好

目前，我们正在问自己这是否是一个好的解决方案： 我们的主要项目是使用依赖项注入来解决依赖项。 因此，我们的项目结构如下：

• 接口（.dll）
• 数据层（.dll）
• 本地化（.dll）
• 基础结构（.dll）
• 应用程序（.exe）

在我看来，我希望将这些内容拆分为更多、更小的解决方案，以保持这些内容的简单性和易用性：

• 接口（仅一个项目：接口定义）
• 组件（三个项目：数据层、本地化和基础架构）
• 应用程序（仅一个项目：仅exe）

这就导致了一个问题：如果有人在更改接口，我们必须在每个组件项目中更新接口的nuget数据包版本，将更改提交到构建系统，然后更新应用程序本身。这有点像DLL地狱-此外，调试和开发是有点困难，若你们尝试，因为有几个项目是分开的

---

这是在胡说八道吗？在您看来，解决依赖关系、减少大型解决方案并将其分解为小型解决方案的最佳选择是什么？或者，您会建议将所有项目整合到一个大型解决方案中吗？

您建议的方法是“如果有人更改接口，我们必须更新每个组件项目中接口的nuget数据包版本，将更改提交到我们的构建系统”事实上，这不是最佳做法，并且在扩展时会导致问题

理想情况下，您希望将包的开发与消费者的开发分开。考虑组件包和应用层。如果当前设置中应用程序项目正在使用组件包的1.0.0.0。有人进入并将一个新组件添加到组件包中，并创建了一个版本1.1.0.0。现在，如果您进入并更新应用程序项目中的组件包，将发生以下事情

新组件包中包含的任何错误修复都会被引入（这可能是一件好事）

添加到包中的任何新组件都将可用于应用程序项目（只有当应用程序将使用新组件时，这才是一件好事，否则它根本不会影响应用程序）

在创建新组件的过程中添加的任何可能无意中影响现有组件功能的新bug也会被引入

在我看来，第3点是软件包更新最危险的影响。每当我知道新版本的软件包将要修复一个bug或引入我在应用程序中需要的新功能时，我都可以冒着添加新bug的风险。然而，如果我不打算使用新组件，我基本上会在应用程序项目中引入不稳定性，而不会带来额外的优势

我建议的程序如下：

将每个软件包的开发与其使用者分开。这种方法可以很好地扩展，并为消费者提供了选择加入新更改的选项

创建一些系统/约定，包的开发人员可以在发布新版本时让消费者知道。适当的发行说明/一个简单的博客也足够了

让使用新软件包的应用程序/项目的开发人员仅在其包含使用者需要的功能时才使用最新版本