什么时候应该将类或模块放在单独的Assembly / DLL中？

是否有任何准则来决定何时将一个类放在其自己的程序集中/ DLL中？我经常看到两种思想流派：

1）每个类的“分组”都属于其自己的DLL，例如存储库，服务，DTO，基础结构等。

2）一切都应在单个DLL中，但应通过名称空间/文件夹分开，例如，具有“ Core” DLL以及其他名称空间，例如Core.Repositories，Core.Services，Core.DTO等。

在工作中，我们将所有组件都集中在一个称为“业务”的程序集中。有一些文件夹，但没有真正的分离-业务对象（带有逻辑，其中一些甚至不应该是类）被放在“ BusinessObjects”文件夹中而不用管。多个类中使用的内容位于“ Core”文件夹中。实用程序位于“实用程序”文件夹中，数据访问基础结构位于“数据”文件夹中-您就明白了。

对于我正在使用的新模块，我希望/需要一个单独的数据访问层（认为是基本的存储库实现），但我不想将其与其他160个一起放到“ BusinessObjects”文件夹下！在那里上课。同时，我担心创建一个新的类库，因为每个人都习惯于将一个类填充到单个库中。文件夹/命名空间可以工作。

我发现在每个项目中拥有更多按类别划分类别的项目（即程序集）比在所有名称空间中包含所有这些类的项目更好。您应该使您的项目具有可重用性，并代表应用程序中的不同层。然后，您可以在将来的应用程序中重用这些项目，而不必包括一大堆不必要的类。

例如，根据您提到的内容，我肯定会拥有以下项目：

• 核心
• 数据
• 域（或BusinessObjects）
• 服务
• 实用程序（或助手）

SOLID Principles清洁代码的“鲍勃叔叔”马丁在这里概述了三个原则：

• 释放重用等效原理：重用粒度是释放粒度。
• 通用闭包原则：一起更改的类打包在一起。
• 通用重用原则：一起使用的类打包在一起。

一般的经验法则是，应使解决方案中的项目数尽可能少。仅在需要时才拆分它们，以实现一个或多个特定的用户故事，或者只有一个程序集会导致可衡量的性能问题（通常是在它们达到几兆字节的大小时）。

我使用的其他一些指导原则：

• 您是否认为您将在其他projectS中重用此代码？对于一组相关的Web应用程序，我们有一个与用户帐户相关的模块，所有应用程序都使用该模块，因为它们都对用户帐户和登录使用相同的模型。我已经通过几何和数学库完成了类似的工作，并通过包含DLL在多个应用程序中重用了它们。

• 您是否希望能够修改/部署此代码而无需重新部署/重新编译整个项目？有时仅重建模块，部署并重新启动Web应用程序很有用。

听起来在您的情况下，基本的通用存储库将来可能再次有用，如果可以的话，将其分离到新的DLL中可能是值得的。