设计原则，如SoC在公共库的上下文中

本文关键字：上下文 原则 SoC | 更新日期: 2023-09-27 18:03:13

我目前正在开发几个功能独立的。net web应用程序(MVC)。我们按照关注点分离对每个项目进行了封装。所以我们最终完成了这样的项目:

应用程序。DataAccess

应用程序。服务

应用程序。WebApi

应用程序。域等

有一大块代码可以在两个组件之间有效地共享，并且这些组件已经被分离到它们自己的项目中。

常见/核心。DataAccess

常见/核心。服务

常见/核心。域

常见/核心。WebApi等

我们现在正在修复的情况是，这个"通用代码"基本上被复制到两个应用程序中，我们正在使用进程作为创可贴，以保持它们在两个应用程序之间同步。

经过一番研究，我的建议是:

1)创建一个私有的nuget feed(托管在我们自己的服务器上)

2)为公共代码提供自己的解决方案，并将其推送到此提要。

3)两个应用程序现在都将这些通用代码作为nuget包安装。

一般来说，每个人都对这种方法很满意。分歧来自于构建这个新解决方案。

Common目前由9个项目组成，其中一些项目像单个类一样小。最大的项目有25个文件那么大。我觉得我们应该将所有内容合并到一个项目中，并使用文件夹和名称空间进行封装。

团队所关心的是，当我们的web项目引用这个nuget包并访问一些Data access组件时，关注点分离将被违反。

这里是否有一个普遍接受的模式要遵循，或者保持9个项目和9个核心包以保持SoC满意的最佳解决方案?

感谢这里的任何指导!

~ Saagar

设计原则，如SoC在公共库的上下文中

没有硬性的指导方针。

    然而，从长远来看，将它们作为单独的nuget包进行管理是有益的。
  • 这通常是因为，很少有9程序集仍然是纯实用程序程序集。它们不可避免地包含了不同关注点的辅助代码，如web api、mvc、加密、认证等。
  • 因此，与其将它们集中为一个单独的项目/nuget包，不如将9个项目与9个nuget包合并成一个解决方案。
  • 否则，你最终会有Web Api, Mvc, Auth, Validation, Data Access, AWS, Azure等代码在这个巨大的程序集中，对于一个只需要加密助手类的消费者来说，有大量不必要的依赖关系。
相关文章：