C# 命名空间和程序集最佳实践

C# Namespaces and Assemblies Best Practice

提问by Rich Oliver

C#: are there any guidelines, best practices when it comes to dividing a solution up into name-spaces and assemblies? Should name spaces normally be nested, with the most low level and fundamental classes in the top level name space? Should there generally be one name-space to one assembly? Are their any pitfalls to having multiple assemblies in one name-space or multiple name-spaces in one assembly. Are there any compile time/ run time penalties for multiple assemblies or very large assemblies?

C#：在将解决方案划分为名称空间和程序集时，是否有任何指导方针和最佳实践？命名空间通常是否应该嵌套，在顶级命名空间中使用最底层和最基础的类？一个程序集通常应该有一个命名空间吗？他们在一个名称空间中拥有多个程序集或在一个程序集中拥有多个名称空间是否存在任何陷阱。对于多个程序集或非常大的程序集，是否有任何编译时/运行时惩罚？

采纳答案by Eric Lippert

C#: are there any guidelines, best practices when it comes to dividing a solution up into name-spaces and assemblies?

C#：在将解决方案划分为名称空间和程序集时，是否有任何指导方针和最佳实践？

For guidelines for namespaces, read the framework design guidelines.

有关命名空间的指南，请阅读框架设计指南。

For assemblies: an assembly is by definition the smallest independently versionable unit of self-describing shippable functionality in .NET. Are there parts of your software that you intend to ship or version independently of each other? Then they should be in different assemblies.

对于程序集：根据定义，程序集是 .NET 中自描述可交付功能的最小独立版本化单元。您打算发布或版本独立的软件部分吗？那么它们应该在不同的程序集中。

Should name spaces normally be nested, with the most low level and fundamental classes in the top level name space?

命名空间通常是否应该嵌套，在顶级命名空间中使用最底层和最基础的类？

Not necessarily, no.

不一定，没有。

Namespaces should be designed so that it is easy for users to discover and understand the types contained in those namespaces. Maybe you should ask your users what they think.

命名空间的设计应该让用户很容易发现和理解这些命名空间中包含的类型。也许你应该问问你的用户他们的想法。

Should there generally be one name-space to one assembly?

一个程序集通常应该有一个命名空间吗？

Not necessarily, no.

不一定，没有。

Are their any pitfalls to having multiple assemblies in one name-space or multiple name-spaces in one assembly.

他们在一个名称空间中拥有多个程序集或在一个程序集中拥有多个名称空间是否存在任何陷阱。

Not particularly, no.

不是特别，没有。

Are there any compile time / run time penalties for multiple assemblies or very large assemblies?

多个程序集或非常大的程序集是否有任何编译时/运行时惩罚？

Not that I'm aware of.

不是我所知道的。

回答by Alexei Levenkov

Namespaces are just fancy way of splitting full class names for user's convenience. So there are no compile/run-time penalties or gains for using namespaces.

命名空间只是为了用户方便而拆分完整类名的奇特方式。因此，使用命名空间没有编译/运行时惩罚或收益。

Splitting objects into assemblies will have impact on run-time and compile time, also it is unlikely to be high if you don't go with very large number of assemblies. Note that it is not possible to predict what you get gains or slowness without actual measurements for your particular case.

将对象拆分为程序集会对运行时间和编译时间产生影响，如果您不使用大量程序集，也不太可能很高。请注意，如果没有针对您的特定情况的实际测量，则无法预测您获得的收益或速度。

You should divide your project into assemblies based on your logical (i.e. by subsystems)/technical(i.e. due to component versioning) needs and than verify if performance is acceptable. If not you'll need to figure out where problems are before blaming it on number of assemblies.

您应该根据您的逻辑（即通过子系统）/技术（即由于组件版本控制）需求将您的项目划分为程序集，然后验证性能是否可以接受。如果不是，您需要在将问题归咎于程序集数量之前弄清楚问题出在哪里。

回答by Kevin Cathcart

To follow up on what Eric Lippert said:

跟进 Eric Lippert 所说的话：

Assembly Names

程序集名称

It is traditional for nearly all code in a assembly to live in a single namespace and sub-namespaces, with the assembly named after the namespace.

传统上，程序集中的几乎所有代码都存在于单个命名空间和子命名空间中，程序集以命名空间命名。

For example, if I was given an assembly with the file name Contoso.PartnerPortal.Services.dll, the assembly's short name would traditionally be Contoso.PartnerPortal.Services, and I would expect the bulk of the code to live in the Contoso.PartnerPortal.Servicesnamespace (and sub-namespaces).

例如，如果给我一个文件名为Contoso.PartnerPortal.Services.dll的程序集，则程序集的短名称传统上是Contoso.PartnerPortal.Services，并且我希望大部分代码位于Contoso.PartnerPortal.Services命名空间（和子命名空间）中。

However not all classes in the Contoso.PartnerPortal.Servicesnamespace will necessarily live in the Contoso.PartnerPortal.Services.dll assembly. If a Contoso.PartnerPortal.dllassembly exists it may well have some classes in the Contoso.PartnerPortal.Servicesnamespace too.

但是，并非Contoso.PartnerPortal.Services命名空间中的所有类都必须位于 Contoso.PartnerPortal.Services.dll 程序集中。如果存在Contoso.PartnerPortal.dll程序集，它也可能在Contoso.PartnerPortal.Services命名空间中有一些类。

One common use of this is with interfaces. If the interfaces live in Contoso.PartnerPortal.dllthen code in that assembly can use the interface without referencing the Contoso.PartnerPortal.Services.dll. This is important, since Contoso.PartnerPortal.Services.dll(which will implement the interfaces) will likely need to reference Contoso.PartnerPortal.dlland circular assembly references are best avoided.

它的一种常见用途是接口。如果接口位于Contoso.PartnerPortal.dll 中，则该程序集中的代码可以在不引用Contoso.PartnerPortal.Services.dll 的情况下使用该接口。这很重要，因为Contoso.PartnerPortal.Services.dll（将实现接口）可能需要引用Contoso.PartnerPortal.dll并且最好避免循环程序集引用。

Number/Size of Assemblies

组件的数量/尺寸

Assemblies that are excessively large may make compilation take longer than necessary. This is because the compilers have not had support for incremental compilation in quite a long time. Thus an entire module must be compiled as a unit. Since multi-module assemblies are not frequently used this basically implies that you must compile a whole assembly at once.

过大的程序集可能会使编译所需的时间更长。这是因为编译器已经很长时间没有支持增量编译了。因此，必须将整个模块编译为一个单元。由于不经常使用多模块程序集，这基本上意味着您必须一次编译整个程序集。

If you split a large assembly into several smaller ones, only the changed assembly and those that reference will get recompiled. That saves some time.

如果将一个大程序集拆分为几个较小的程序集，则只有更改的程序集和引用的程序集将被重新编译。这样可以节省一些时间。

On the other extreme having over 600 assemblies in one application (I work on such a monster in my day job) has its own set of problems. For example, the shadow copy feature of ASP.net has had performance issues working with that many assemblies (keep in mind that this is in addition to the large number of assemblies created when ASP.net compiles the aspx and ascx files).

另一方面，在一个应用程序中拥有 600 多个程序集（我在日常工作中处理这样一个怪物）有其自身的一系列问题。例如，ASP.net 的卷影复制功能在处理这么多程序集时存在性能问题（请记住，这是在 ASP.net 编译 aspx 和 ascx 文件时创建的大量程序集之外的）。