公共库上下文中的 SoC 等设计原则
Design principles like SoC in the context of a common library
我目前正在开发几个功能独立的 .NET Web 应用程序 (MVC)。在关注点分离之后，我们将每个项目封装起来。所以我们最终完成了如下项目：
App.DataAccess
App.Services
App.WebApi
App.Domain
等等
有一大块代码可以在两个组件之间有效地共享，并且这些代码已经分离到它们自己的项目中。
Common/Core.DataAccess
Common/Core.服务
Common/Core.域
Common/Core.WebApi
等等
我们现在正在努力解决的问题是，这个 'Common code' 基本上复制到两个应用程序，我们正在使用流程作为创可贴，使它们在两个应用程序之间保持同步。
经过一些研究，我目前的建议是：
1) 创建私人 nuget 提要（托管在我们自己的服务器上）
2) 为通用代码提供自己的解决方案并将其推送到此提要。
3) 两个应用程序现在都将此通用代码安装为 nuget 包。
总的来说，每个人都对这种做法感到满意。分歧来自构建这个新解决方案。
Common 目前由 9 个项目组成，有些项目小到只有一个 class。最大的项目小于 25 个文件。我觉得我们应该把所有的东西都整合到一个项目中，用文件夹和命名空间来封装。
团队担心的是，由于我们的 Web 项目将引用此 nuget 包并可以访问某些数据访问组件，因此会违反关注点分离。
这里是否有一个普遍接受的模式可以遵循，或者是保持 9 个项目和 9 个 nuget 包以满足 SoC 的最佳解决方案？
在此感谢任何指导！
~萨格
没有硬性规定。
- 然而，从长远来看，将它们作为单独的 nuget 包进行管理是有益的 运行。
- 这通常是因为，很少有 9 个程序集保留为纯实用程序程序集。它们不可避免地包含跨不同问题的帮助程序代码，例如 web api、mvc、密码学、auth 等
- 因此，与其将它们归为 1 个 project/nuget 包，不如将 9 个项目放在一个包含 9 个 nuget 包的解决方案中。
- 否则，您最终会在这个巨大的组件中拥有 Web Api、Mvc、Auth、Validation、Data Access、AWS、Azure 等代码，对于只需要加密的消费者来说，有大量不需要的依赖项助手 class.
我目前正在开发几个功能独立的 .NET Web 应用程序 (MVC)。在关注点分离之后，我们将每个项目封装起来。所以我们最终完成了如下项目：
App.DataAccess
App.Services
App.WebApi
App.Domain 等等
有一大块代码可以在两个组件之间有效地共享，并且这些代码已经分离到它们自己的项目中。
Common/Core.DataAccess
Common/Core.服务
Common/Core.域
Common/Core.WebApi 等等
我们现在正在努力解决的问题是，这个 'Common code' 基本上复制到两个应用程序，我们正在使用流程作为创可贴，使它们在两个应用程序之间保持同步。
经过一些研究，我目前的建议是：
1) 创建私人 nuget 提要（托管在我们自己的服务器上）
2) 为通用代码提供自己的解决方案并将其推送到此提要。
3) 两个应用程序现在都将此通用代码安装为 nuget 包。
总的来说，每个人都对这种做法感到满意。分歧来自构建这个新解决方案。
Common 目前由 9 个项目组成，有些项目小到只有一个 class。最大的项目小于 25 个文件。我觉得我们应该把所有的东西都整合到一个项目中，用文件夹和命名空间来封装。
团队担心的是，由于我们的 Web 项目将引用此 nuget 包并可以访问某些数据访问组件，因此会违反关注点分离。
这里是否有一个普遍接受的模式可以遵循，或者是保持 9 个项目和 9 个 nuget 包以满足 SoC 的最佳解决方案？
在此感谢任何指导！
~萨格
没有硬性规定。
- 然而，从长远来看，将它们作为单独的 nuget 包进行管理是有益的 运行。
- 这通常是因为，很少有 9 个程序集保留为纯实用程序程序集。它们不可避免地包含跨不同问题的帮助程序代码，例如 web api、mvc、密码学、auth 等
- 因此，与其将它们归为 1 个 project/nuget 包，不如将 9 个项目放在一个包含 9 个 nuget 包的解决方案中。
- 否则，您最终会在这个巨大的组件中拥有 Web Api、Mvc、Auth、Validation、Data Access、AWS、Azure 等代码，对于只需要加密的消费者来说，有大量不需要的依赖项助手 class.