NET：对于文件之间划分的命名空间的最佳做法/准则？ [英] NET: Best Practices/guidelines for dividing namespaces between files?

问题描述

应该是什么的一般准则/陷阱用于将应用code（APP_ code）到单独的文件？

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

我发现，随着时间的推移，原来的文件不匹配以及有多大的空间层次的发展。我该如何保持组织直观地随着时间的推移应用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?

什么目的应该文件师对目标？ code便携性？关注点分离？一般功能方面？变化的频率是多少？他们应该争取1-1类的关系？

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?

什么是分裂code成许多小文件VS合并成几个文件的含义是什么？

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.

推荐答案

在回答这个问题也不是绝对的，因为它往往取决于你手边的任务。如果你建立某种SDK的复用别人的，然后命名空间是很重要的;但是，如果你正在创建一个内部工具，只需几个班，命名空间是pretty的多少不重要。

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.

一般而言，类应该有自己的文件，因为这简化了人们浏览周围的code解决方案，开发和维护的帮助（这是更难合并更改时，每个人都改变了相同的文件，例如）。它可以接受在某些情况下，如拆分为多个文件，一个类：

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.

在有自动生成的部分，以类如设计师code。

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.

命名空间一般应专注于你的类型的明智分组。命名空间应允许开发人员可以直观地找到他们所期待的。对于许多小项目，一个命名空间，例如 MyAwesomeTool 就足够了，但对于许多类一个较大的项目将需要更多的逻辑分组。如此大的项目，如软件开发工具包或.net BCL依靠命名空间击穿，否则压倒性大集合类型。每个命名空间级别提供了什么可能会在那里发现的其他信息，如 System.Windows.Forms的或 System.Drawing中或 Microsoft.VisualBasic程序。

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 MyAwesomeTool is 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.Forms or System.Drawing or 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.

有没有工作在各种情况下的硬性规定。你如何安排你的code到文件中涉及到自己的发展进程，影响您和您的团队;所有的类在一个文件将是地狱发展与但汇编产品将不会起到任何的不同（提供的一个文件的做法并没有导致错误），而您的命名空间的布局涉及到今后的发展和消费者这些命名空间，所以得到的结果是错误的可能是更严重的。

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.

• 目标来组织的，简化了当前发展和未来维护的方式你的类。
• 目标来组织你的命名空间，简化了所有开发的方式，并在适当情况下，你的最终用户体验。

这篇关于NET：对于文件之间划分的命名空间的最佳做法/准则？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！