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

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

对于程序集：根据定义，程序集是.NET中自我描述的可交付功能的最小可独立版本单元。您的软件中是否有打算相互独立交付或版本的部分？然后它们应该在不同的程序集中。

名称空间通常应该嵌套，最低级和最基本的类在顶级名称空间中吗？

不一定，没有。

命名空间的设计应便于用户发现和理解这些命名空间中包含的类型。也许你应该问问用户的想法。

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

不一定，没有。

在一个名称空间中有多个程序集或在一个程序集中有多个名称空间，它们有什么陷阱吗。

不特别，没有。

对于多个程序集或非常大的程序集，是否存在编译时/运行时惩罚？

我不知道。

跟进Eric Lippert所说的话：

程序集名称

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

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

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

它的一个常见用途是接口。如果接口位于Contoso.PartnerPortal.dll中，则该程序集中的代码可以使用该接口，而无需引用Contoso.PrtnerPortal.Services.dll.这一点很重要，由于Contoso.PartnerPortal.Services.dll（将实现接口）可能需要引用Contoso.PrtnerPortal.dll

组件的数量/尺寸

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

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

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

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

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

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