visual-studio NET：在文件之间划分命名空间的最佳实践/指南？

NET: Best Practices/guidelines for dividing namespaces between files?

提问by Matias Nino

What should be the general guidelines/gotchas for dividing application code (App_Code) into separate files?

将应用程序代码 (App_Code) 划分为单独文件的一般准则/问题应该是什么？

I've found that over time, the original files do not match up well with how the namespace hierarchy evolves. How do I keep application code containers organized intuitively over time?

我发现随着时间的推移，原始文件与命名空间层次结构的演变方式不太匹配。如何让应用程序代码容器随着时间的推移直观地组织起来？

What PURPOSE should the file divisions aim towards? Code portability? Separation of concerns? General functional context? Frequency of change? Should they strive for 1-1 relationship with classes?

档案部门的目标是什么？代码可移植性？关注点分离？一般功能上下文？变化频率？他们应该争取与班级的 1-1 关系吗？

What are the implications of splitting the code into MANY smaller files vs consolidated into few files?

将代码拆分为许多较小的文件与合并为几个文件的含义是什么？

I've often thought about this but never really reached any general conclusions that apply to all situations.

我经常考虑这个问题，但从未真正得出适用于所有情况的一般结论。

回答by Jeff Yates

The answer to this question is not absolute as it often depends on the task you have at hand. If you're creating some kind of SDK for reuse by others, then namespaces are very important; however, if you're creating an in-house tool with just a few classes, the namespaces are pretty much unimportant.

这个问题的答案不是绝对的，因为它通常取决于您手头的任务。如果您正在创建某种 SDK 以供其他人重用，那么命名空间非常重要；然而，如果您正在创建一个只有几个类的内部工具，那么命名空间就变得不重要了。

Classes

班级

Generally speaking, classes should have their own file as this simplifies how people navigate around the code solution, helping with development and maintenance (it's much harder to merge changes when everyone is changing the same files, for example). It can be acceptable to split one class across multiple files in some situations such as:

一般来说，类应该有自己的文件，因为这简化了人们在代码解决方案中导航的方式，有助于开发和维护（例如，当每个人都更改相同的文件时，合并更改要困难得多）。在某些情况下，将一个类拆分为多个文件是可以接受的，例如：

• When there are nested classes, each nested class could have its own file.

• When there are auto-generated portions to the class such as designer code.

• When there are fixed portions to the class such as a common set of hidden properties or a common implementation of an interface.

• 当有嵌套类时，每个嵌套类都可以有自己的文件。

• 当类有自动生成的部分时，例如设计器代码。

• 当类有固定部分时，例如一组公共隐藏属性或接口的公共实现。

In one of our projects, we have a common implementation of an interface that many classes expose. As we don't have multiple inheritance, we take a mix-in approach whereby we autogenerate an additional file for each class. This could be done manually, instead of automatically (and was, originally).

在我们的一个项目中，我们有许多类公开的接口的通用实现。由于我们没有多重继承，我们采用混合方法为每个类自动生成一个附加文件。这可以手动完成，而不是自动完成（并且最初是）。

There are other situations, but this is somewhat subjective and dependent on your own project's requirements.

还有其他情况，但这有点主观，取决于您自己的项目需求。

Namespaces

命名空间

Namespaces should generally focus on sensible groupings of your types. A namespace should allow a developer to intuitively locate what they are looking for. For many small projects, a single namespace such as MyAwesomeToolis sufficient, but for a larger project with many classes will need a more logical grouping. Such large projects, like SDKs or the .NET BCL rely on the namespaces to breakdown the otherwise overwhelmingly large collection of types. Each namespace level provides additional information of what might be found there, such as System.Windows.Formsor System.Drawingor Microsoft.VisualBasic.

命名空间通常应该关注您的类型的合理分组。命名空间应该允许开发人员直观地定位他们正在寻找的内容。对于许多小型项目，单个命名空间（例如）MyAwesomeTool就足够了，但对于具有许多类的较大项目，则需要更符合逻辑的分组。诸如 SDK 或 .NET BCL 之类的大型项目依赖于命名空间来分解原本非常庞大的类型集合。每个命名空间级别都提供了可能在那里找到的内容的附加信息，例如System.Windows.FormsorSystem.Drawing或Microsoft.VisualBasic。

When creating namespaces, every consideration must be given to the purpose of that namespace and the associated project. If the project is in-house and small, call the namespace what you like as it is merely a necessity for grouping your types; if the project is externally visible or contains a large amount of types, think carefully about logical and meaningful groupings that will enable others to intuitively find the types they are looking for.

创建命名空间时，必须考虑该命名空间和相关项目的用途。如果项目是内部的并且很小，请根据您的喜好调用命名空间，因为它只是对您的类型进行分组的必要条件；如果项目是外部可见的或包含大量类型，请仔细考虑逻辑和有意义的分组，这将使其他人能够直观地找到他们正在寻找的类型。

Conclusion

结论

There are no hard and fast rules that work in every situation. How you arrange your code into files relates to your own development processes, impacting you and your team; all your classes in one file will be hell to develop with but the compiled product won't act any different (provided the one file approach didn't lead to errors), whereas the arrangement of your namespaces relates to future development and the consumers of those namespaces, so the consequences of getting it wrong can be more serious.

没有适用于所有情况的硬性规定。您如何将代码整理到文件中，这与您自己的开发流程相关，从而影响您和您的团队；一个文件中的所有类都将很难开发，但编译后的产品不会有任何不同（前提是单一文件方法不会导致错误），而命名空间的安排与未来的开发和消费者有关那些命名空间，所以出错的后果可能会更严重。

• Aim to organise your classes in a way that simplifies current development and future maintenance.
• Aim to organise your namespaces in a way that simplifies all development and, where appropriate, the experience of your end users.

• 旨在以简化当前开发和未来维护的方式组织您的课程。
• 旨在以简化所有开发的方式组织命名空间，并在适当的情况下简化最终用户的体验。

回答by Andrew Grant

There should be a one-to-one mapping between classes and source files.

类和源文件之间应该是一对一的映射。

Namespaces should be thought of as a package that may encompass one or more classes. Where possible it can be useful to represent these as folders/filters in the Visual Studio project window.

命名空间应该被认为是一个包含一个或多个类的包。在可能的情况下，将这些表示为 Visual Studio 项目窗口中的文件夹/过滤器会很有用。

If you find a sizeable class you feel would benefit from being split into separate files then instead consider refactoring and splitting the class itself.

如果您发现一个相当大的类，您认为将其拆分为单独的文件会有所帮助，那么请考虑重构和拆分类本身。

The (acceptable) exception to this is the code that generates the UI which Visual Studio places in a separate file. I would recommend leaving this in its own file and treating it as a transparent editor-owned file as much as possible.

对此的（可接受的）例外是生成 UI 的代码，Visual Studio 将其放置在单独的文件中。我建议将其保留在自己的文件中，并尽可能将其视为透明的编辑器所有文件。

回答by Mehrdad Afshari

Most recommendations I saw say that every public type should be in its own file and namespaces should represent the folder structure of the application.

我看到的大多数建议都说每个公共类型都应该在自己的文件中，命名空间应该代表应用程序的文件夹结构。

回答by Charles Graham

I do 99% 1 to 1 class to file. The only exception is if you have a large number or very simple little classes that all implement the same interface and shouldn't change much. You might want to just go ahead and put these in one file. Custom exceptions can be a good example. Most of the time (in my experience), there is no code other than creating custom messages or things of that nature.

我做了 99% 的一对一课程来归档。唯一的例外是，如果您有大量或非常简单的小类，它们都实现了相同的接口并且不应有太大变化。您可能只想继续将这些放在一个文件中。自定义异常就是一个很好的例子。大多数时候（根据我的经验），除了创建自定义消息或此类性质的东西之外，没有其他代码。

Namespaces should be organized first by separation of concerns. The Data objects should be in a different namespace than the domain objects, for example. Then, you might have a smaller subdomain for each group of objects at the "aggregate root" level. Usually, each of these smallest namespaces corresponds to its own project and DLL.

命名空间应该首先通过关注点分离来组织。例如，数据对象应该位于与域对象不同的命名空间中。然后，您可能在“聚合根”级别为每组对象拥有一个较小的子域。通常，这些最小命名空间中的每一个都对应于自己的项目和 DLL。

回答by Chris Cudmore

As far as classes go, I tend to follow the Java rule: "One Public class per file" I may include a private class in with the public if that public class is the sole user. (Although, enums are making this less of a factor); However, if it's used by many public classes in the same namespace, then I'll put it in it's own file.

就类而言，我倾向于遵循 Java 规则：“每个文件一个公共类”如果公共类是唯一的用户，我可能会在公共类中包含一个私有类。（虽然，枚举使这不再是一个因素）；但是，如果它被同一命名空间中的许多公共类使用，那么我会将它放在它自己的文件中。

I'll tend to use namespaces along the lines of:

我会倾向于使用以下方面的命名空间：

MyAwesomeApp.UI
MyAwesomeApp.Business
MyAwesomeApp.Data

MyAwesomeApp.UI
MyAwesomeApp.Business
MyAwesomeApp.Data

to reflect the seperation of layers.

体现层次分明。