C＃命名空间和程序集最佳实践
C＃：在将解决方案划分为名称空间和程序集时，是否有任何指导方针和最佳实践？ 名称空间通常应该嵌套，顶层名称空间中的最低级别和基础类是什么？ 一般会有一个名称空间到一个程序集吗？ 在一个名称空间中有多个程序集或在一个程序集中有多个名称空间是他们的任何陷阱。 多个组件或非常大的组件是否有编译时间/运行时间的惩罚？
C＃：在将解决方案划分为名称空间和程序集时，是否有任何指导方针和最佳实践？
有关命名空间的指南，请阅读框架设计指南。
对于程序集：根据定义，程序集是.NET中自描述可自由发送function的最小独立可版本单元。 您打算发布的软件部分是否相互独立？ 然后他们应该在不同的集会。
名称空间通常应该嵌套，顶层名称空间中的最低级别和基础类是什么？
不一定，没有。
应该设计命名空间，以便用户可以轻松发现和理解这些命名空间中包含的类型。 也许你应该问你的用户他们的想法。
一般会有一个名称空间到一个程序集吗？
不一定，没有。
在一个名称空间中有多个程序集或在一个程序集中有多个名称空间是他们的任何陷阱。
不是特别，不。
多个组件或非常大的组件是否有编译时间/运行时间的惩罚？
不是我知道的。
跟进Eric Lippert所说的话：
assembly名称
对于程序集中的几乎所有代码来说，传统上都存在于单个命名空间和子命名空间中，而程序集以命名空间命名。
例如，如果给我一个文件名为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.PartnerPortal.Services.dll 。 这很重要，因为Contoso.PartnerPortal.Services.dll （将实现接口）可能需要引用Contoso.PartnerPortal.dll，并且最好避免使用循环程序集引用。
assembly的数量/尺寸
过大的程序集可能会使编译时间超过必要的时间。 这是因为编译器在相当长的时间内没有支持增量编译。 因此，必须将整个模块编译为一个单元。 由于多模块程序集不经常使用，这基本上意味着您必须一次编译整个程序集。
如果将大型assembly拆分为几个较小的assembly，则仅重新编译已更改的assembly和引用的assembly。 这节省了一些时间。
另一方面，在一个应用程序中有超过600个程序集（我在日常工作中处理这样的怪物）有其自身的一系列问题。 例如，ASP.net的卷影复制function在使用许多程序集时遇到了性能问题（请记住，除了ASP.net编译aspx和ascx文件时创建的大量程序集之外）。
命名空间只是为了方便用户而拆分完整类名的奇特方式。 因此，使用命名空间没有编译/运行时惩罚或收益。
将对象拆分为程序集会对运行时和编译时产生影响，如果不使用大量的程序集，也不会很高。 请注意，如果没有针对您的特定情况进行实际测量，则无法预测您获得的收益或缓慢程度。
您应该根据您的逻辑（即子系统）/技术（即由于组件版本控制）需求将项目划分为程序集，并validation性能是否可接受。 如果没有，你需要在将它归咎于组件数量之前找出问题所在。