将我的类/接口排列/组织到文件夹中？不更改文件夹的命名空间（Resharper：命名空间提供程序 = false）
我目前有一个项目，并且其规模每天都在增加。它是我提供的 api 的容器。
目前，我的所有类和所有接口都在根目录中。
我已将枚举、常量等分离到它们自己的文件夹中，但我不会继承该文件夹作为命名空间的一部分，它们只是保持整洁的容器。
我想知道有人有这里的经验吗？
我是否也应该将我的接口分离到它们自己的文件夹中（不继承该文件夹作为命名空间的一部分）
我也应该将我的类分离吗？
我也有一些类是其他类的子类..即类将其实现为属性。因此它永远不会在外部实例化。那么我是否应该进一步将它们分开并放置（例如）一个名为“Products”的文件夹，在这个文件夹中我将拥有我的产品类，然后是我的项目类和其他特定于产品的类？
同样，使用文件夹作为分隔的手段，而不是继承文件夹名称作为命名空间的一部分。
我很想听到一些反馈。
谢谢
I currently have a project and its increasing in size everyday. Its a container for an api i am providing.
I currently have in the root all my classes and all interfaces.
I have separated my Enums, Contants, etc into their own folders but i don't inherit the folder as part of the namespace they are just containers to keep them tidy.
I was wondering if anybody has any experience here?
Should i separate my interfaces into their own folder too (not inheriting the folder as part of namespace)
Should i separate my classes also?
I also have classes that are children of other classes .. ie a class implements it as a property. Hence it would never be instantiated outside. So should I separate them even further and put (for example) a folder called "Products" and inside this folder i would have my Product class and then my item class and other classes that are specific to Product?
Again, using the folder as a means of separating and not inheriting the folder name as part of the namespace.
I would love to hear some feedback.
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这种情况在开发中很少出现。事实上，在大多数情况下，您最终会拥有单独的项目，而不是具有大量文件夹的单个项目。就我个人而言，我认为复杂的项目有明显的代码味道。如果不出意外，您的项目将不会编译得那么快，因为它被编译为一个块，而单独的项目可以并行编译（或多或少 - 它都受到依赖关系的影响）。
也就是说，如果您确实想将所有内容保留在一个项目中，那么我的看法是：
Infrastruct的文件夹>，确保它不是名称空间提供者并将所有常见内容放在那里。Entities的文件夹（因此MyProject.Entities的命名空间），其中在单个位置包含枚举和类。 （另请注意，如果您突然将其迁移到名为MyProject.Entities的项目，则无需更改名称空间。）总而言之 - 尝试按功能而不是按类型对文件进行分组。
These kinds of situations rarely arise in development. In actual fact, in most cases you end up having separate projects rather than a single project with lots and lots of folders. Personally I consider a convoluted project an obvious code smell. If nothing else, your project won't compile as quickly because it gets compiled as a chunk, whereas separate projects can be compiled in parallel (more or less - it's all influenced by dependencies).
That said, if you really want to keep everything in one project, here's my take on it:
Infrastructure, ensure it's not a namespace provider and put all common stuff there.Entities(and thus a namespace ofMyProject.Entities) that contains both the enums and the classes in a single location. (Note also that if you were to suddenly migrate this to a project calledMyProject.Entitiesyou wouldn't have to change your namespaces.)To sum up - try grouping files by functionality, not by type.