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