.net - 将我的类/接口(interface)安排/组织到文件夹中？不使用文件夹更改命名空间(Resharper : Namespace Provider = false)

Question

我目前有一个项目，其规模每天都在增加。它是我提供的 api 的容器。

我目前在根目录中拥有我的所有类和所有接口(interface)。

我已将我的 Enums、Contants 等分隔到它们自己的文件夹中，但我不继承该文件夹作为命名空间的一部分，它们只是保持它们整洁的容器。

我想知道是否有人在这里有任何经验？

我是否也应该将我的接口(interface)分离到它们自己的文件夹中(不继承文件夹作为命名空间的一部分)

我也应该分开上课吗？

我也有其他类的子类.. 即一个类将它作为一个属性来实现。因此它永远不会在外部实例化。那么我是否应该进一步将它们分开并放置(例如)一个名为“Products”的文件夹，在这个文件夹中我会有我的产品类，然后是我的项目类和其他特定于产品的类？

同样，使用文件夹作为一种分离方式，而不是将文件夹名称作为命名空间的一部分继承。

我很想听听一些反馈。

谢谢

Answer 1

这类情况在开发中很少出现。实际上，在大多数情况下，您最终会拥有单独的项目，而不是拥有大量文件夹的单个项目。就我个人而言，我认为一个复杂的项目是一种明显的代码味道。如果不出意外，您的项目将不会编译得那么快，因为它被编译为一个 block ，而单独的项目可以并行编译(或多或少 - 它都受到依赖项的影响)。

也就是说，如果你真的想把所有东西都放在一个项目中，我的看法是:

如果项目的所有元素都有共同点(例如，有用的扩展方法)，我会创建一个名为 Infrastructure 的文件夹。 ，确保它不是 namespace 提供程序，并将所有常见的东西放在那里。

我尝试根据行为而不是类型来分离项目的其余部分。例如，您建议将枚举和类分开，但这对我来说似乎是错误的 - 如果我的数据库实体是类或枚举，我宁愿有一个名为 Entities 的文件夹(因此是 MyProject.Entities 的命名空间)，在单个位置包含枚举和类。 (另请注意，如果您突然将其迁移到名为 MyProject.Entities 的项目中，则不必更改命名空间。)

总而言之-尝试按功能而不是按类型对文件进行分组。