NET：在文件之间划分命名空间的最佳实践/指南？
将应用程序代码 (App_Code) 划分为单独文件的一般准则/陷阱应该是什么？
我发现随着时间的推移，原始文件与命名空间层次结构的演变不太匹配。 随着时间的推移，如何保持应用程序代码容器的直观组织？
档案部门应该达到什么目的？ 代码可移植性？ 关注点分离？ 一般功能上下文？ 变化频率？ 他们应该努力与班级建立1-1的关系吗？
将代码拆分为许多较小的文件与合并为几个文件有何影响？
我经常思考这个问题，但从未真正得出任何适用于所有情况的普遍结论。
What should be the general guidelines/gotchas for dividing application code (App_Code) into separate files?
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?
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
这个问题的答案不是绝对的，因为它通常取决于您手头的任务。 如果您正在创建某种可供其他人重用的 SDK，那么命名空间就非常重要； 但是，如果您要创建仅包含几个类的内部工具，则名称空间几乎不重要。
类
一般来说，类应该有自己的文件，因为这简化了人们浏览代码解决方案的方式，有助于开发和维护（例如，当每个人都更改相同的文件时，合并更改要困难得多）。 在某些情况下，将一个类拆分到多个文件中是可以接受的，例如：
当存在嵌套类时，每个嵌套类可以有自己的文件。
当类有自动生成的部分（例如设计器代码）时。
当类有固定部分时，例如一组公共隐藏属性或公共接口实现。
当类有固定部分时，例如
在我们的一个项目中，我们有一个许多类公开的接口的通用实现。 由于我们没有多重继承，因此我们采用混合方法，为每个类自动生成一个附加文件。 这可以手动完成，而不是自动完成（最初也是如此）。
还有其他情况，但这有些主观，取决于您自己项目的要求。
命名空间
命名空间通常应该关注类型的合理分组。 命名空间应该允许开发人员直观地找到他们正在寻找的内容。 对于许多小型项目，单个命名空间（例如 MyAwesomeTool）就足够了，但对于具有许多类的较大项目，将需要更逻辑的分组。 此类大型项目（例如 SDK 或 .NET BCL）依赖命名空间来分解极其庞大的类型集合。 每个命名空间级别都提供可能在其中找到的内容的附加信息，例如 System.Windows.Forms 或 System.Drawing 或 Microsoft.VisualBasic。
创建命名空间时，必须充分考虑该命名空间和关联项目的用途。 如果项目是内部的且规模较小，则可以根据自己的喜好命名命名空间，因为它只是对类型进行分组的必要条件； 如果项目是外部可见的或包含大量类型，请仔细考虑逻辑和有意义的分组，这将使其他人能够直观地找到他们正在寻找的类型。
结论
没有适用于所有情况的硬性规则。 如何将代码整理到文件中与您自己的开发流程相关，会影响您和您的团队； 一个文件中的所有类将很难进行开发，但编译后的产品不会有任何不同（假设单文件方法不会导致错误），而命名空间的安排与未来的开发和消费者相关这些命名空间，因此出错的后果可能会更严重。
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.
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 asSystem.Windows.FormsorSystem.DrawingorMicrosoft.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.
类和源文件之间应该存在一对一的映射。
命名空间应被视为可能包含一个或多个类的包。 如果可能，在 Visual Studio 项目窗口中将它们表示为文件夹/过滤器会很有用。
如果您发现一个相当大的类，您认为将其拆分为单独的文件会受益，那么请考虑重构并拆分该类本身。
对此的（可接受的）例外是生成 UI 的代码，Visual Studio 将其放置在单独的文件中。 我建议将其保留在自己的文件中，并尽可能将其视为透明的编辑器拥有的文件。
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.
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.
我看到的大多数建议都说每个公共类型都应该位于自己的文件中，并且命名空间应该代表应用程序的文件夹结构。
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.
我99%都是一对一的上课来归档。 唯一的例外是，如果您有大量或非常简单的小类，它们都实现相同的接口并且不应进行太多更改。 您可能只想继续将它们放入一个文件中。 自定义异常就是一个很好的例子。 大多数时候（根据我的经验），除了创建自定义消息或类似性质的东西之外，没有任何代码。
命名空间应该首先通过关注点分离来组织。 例如，数据对象应该位于与域对象不同的命名空间中。 然后，您可能在“聚合根”级别为每组对象拥有一个较小的子域。 通常，每个最小的命名空间都对应于它自己的项目和 DLL。
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.
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.
就类而言，我倾向于遵循 Java 规则：“每个文件一个公共类”
如果该公共类是唯一用户，我可以将私有类包含在公共类中。 （尽管，枚举使这个因素不再那么重要）； 但是，如果它被同一名称空间中的许多公共类使用，那么我会将它放在它自己的文件中。
我倾向于使用以下命名空间：
MyAwesomeApp.UI
MyAwesomeApp.Business
MyAwesomeApp.Data
来体现层的分离。
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.
I'll tend to use namespaces along the lines of:
MyAwesomeApp.UI
MyAwesomeApp.Business
MyAwesomeApp.Data
to reflect the seperation of layers.