我的背景主要是作为一名 Java 开发人员，但最近我一直在做一些 .NET 方面的工作。所以我一直在尝试在家里做一些简单的项目来更好地使用.NET。我已经能够将我的大部分 Java 经验转移到使用 .NET（特别是 C#）中，但唯一真正让我困惑的是命名空间。
我知道命名空间类似于 Java 包，但据我所知，主要区别在于 Java 包使用实际的文件夹来显示分隔，而在 .NET 中则没有，所有文件都驻留在一个文件夹，命名空间简单地在每个类中声明。
我觉得这很奇怪，因为我一直将包视为组织和分组相关代码的一种方式，使其更易于导航和理解。由于在 .NET 中它不能以这种方式工作，因此随着时间的推移，项目显得更加拥挤，并且不那么容易导航。
我在这里遗漏了什么吗？我必须。我应该在解决方案中将事情分解成单独的项目吗？或者有没有更好的方法来组织项目中的类和文件？
编辑：正如布莱尔指出的，这与here 提出的问题几乎相同。
【问题讨论】：
标签： .net namespaces
不同之处在于 .net 命名空间与 java 包没有太大关系。
.net 命名空间纯粹用于管理声明范围，与文件、项目或其位置无关。
非常简单，在特定命名空间中声明的所有内容都可以在以下情况下访问 您在该命名空间中包含一个“使用”。
很简单。
名称的选择以及是否/有多少'.'您使用的分隔符完全取决于您。
VS 默认添加 .foldernames 到你的命名空间只是为了尝试和提供帮助。
这篇文章很好地解释了命名空间： http://www.blackwasp.co.uk/Namespaces.aspx
它最后还有一个示例命名约定，尽管您的命名约定是您的决定！ ;)
也就是说，我工作过的大多数地方和与我共事过的人都以公司名称开头，这是明智的，因为它使该公司的类型名与众不同，（与其他库、供应商、开源项目等分开。 )
【讨论】：
命名空间是一个逻辑分组，而项目是一个物理分组。
为什么这很重要？想想 .NET 2.0、3.0 和 3.5。 .NET 3.0 基本上是带有一些额外程序集的 .NET 2.0，而 3.5 添加了更多程序集。例如，.NET 3.5 添加了DataPager 控件，它是一个Web 控件，应归入System.Web.UI.WebControls。如果命名空间和物理位置相同，则不可能是因为它位于不同的程序集中。
因此，将命名空间作为独立的逻辑实体意味着您可以拥有多个不同程序集的成员，这些程序集都在逻辑上组合在一起，因为它们旨在相互结合使用。
（此外，让您的物理布局和逻辑布局非常相似并没有错。）
【讨论】：
是的，在 .NET 命名空间中不依赖于文件系统或其他任何东西。在我看来，这是一个很大的优势。例如，您可以将代码拆分为不同的程序集，从而实现灵活的分发。
在 Visual Studio 中工作时，IDE 倾向于在您将新文件夹添加到项目树时引入新的命名空间。
这是一个来自 MSDN 的有用链接：
命名空间的一般规则 是使用公司名称后跟 技术名称和可选的 功能和设计如下。
CompanyName.TechnologyName[.Feature][.Design]
当然，您可以以您认为更合适的方式使用命名空间。但是，如果您要共享代码，我建议您遵循公认的标准。
编辑：
我强烈建议任何 .net 开发人员获取一份Framework design guidelines 的副本，这本书将帮助您了解如何以及为什么设计 .NET。 p>
【讨论】：
我不能说这是最佳实践，但我经常看到文件组织在一个目录层次结构中，该目录层次结构反映了命名空间。如果它更适合您的代码心智模型，那么就这样做 - 我想不出有什么害处。仅仅因为 .NET 模型不强制命名空间、项目和目录结构之间的关系并不意味着您不能拥有这样的关系。
我对将代码分解成比您需要的更多项目有点谨慎，因为这会减慢编译速度并在您必须管理多个程序集时增加一点开销。
编辑：请注意，这个问题几乎与 should the folders in a solution match the namespace? 重复
【讨论】：
我一直认为源文件组织和为类和对象分配标识符是两个独立的问题。我倾向于将相关类保存在组中，但并非每个组都应该是一个命名空间。命名空间的存在（或多或少）是为了解决命名冲突的问题——在像 C 这样的平面命名空间语言中，你不能走两英尺而不被 mycompany_getcurrentdate 或 MYCGetCurrentDate 这样的标识符绊倒，因为与第三方（或系统）库中的另一个函数要小得多。如果您为每个逻辑分隔创建一个包或命名空间，您将获得（Java 示例）类名称，如 java.lang.primitivewrapper.numeric.Integer，这几乎是多余的。
【讨论】：
VS 解决方案通常包含一个或多个项目。这些项目具有默认命名空间（通常命名空间就是项目的名称）。通常情况下，如果你在项目中添加一个文件夹，其中的所有类都将命名如下：
DefaultNamespace.FolderName.ClassName
当然，您可以更改项目的默认命名空间，并以您希望的任何方式命名您的类。
至于何时/如何将内容分解为项目，这取决于经验和/或偏好。但是，您绝对应该在解决方案中将内容分解为项目，以使您的项目井井有条。如果管理太多程序集变得很麻烦（正如 Blair 建议的那样），您始终可以将您的程序集 ILMerge 合并为一个程序集。 ILMerge 的优点在于，即使您最终只有一个程序集，您的所有类都保留其原始的完全限定名称。
同样重要的是要记住 VS 解决方案与代码无关 - 即。他们没有被建造。 VS Solutions 只不过是一种对项目进行分组的方式；它是构建并转换为 DLL 的项目。
最后，VS 让您可以在解决方案的任何位置添加“虚拟”文件夹。这些文件夹不映射到文件系统中的文件夹，只是用作帮助您在解决方案中组织项目和其他工件的另一种方式。
【讨论】：
确实，.Net 环境允许您将代码扔到 IDE/文件系统，就像意大利面靠墙一样。
但是，这并不意味着这种方法是明智的。坚持前面提到的 project.foldername.Class 方法通常是一个好主意。将一个命名空间中的所有类保存到同一个类中也是一个非常好的主意。
在 Java 中，您可以做这样的麻烦事，同时获得您想要的所有“灵活性”，但这些工具往往会强烈反对它。老实说，在被介绍给 .Net 世界时，对我来说最令人困惑的事情之一就是由于相对较差的指导，这可能是多么草率/不一致。不过，只要稍加思考，就很容易理智地组织事情。 :)
【讨论】：
命名空间是纯语义的。虽然它们通常确实反映了文件夹结构，但至少在使用 Visual Studio IDE 时，它们不需要这样做。
你可以在多个库中引用相同的命名空间，丑陋但真实。
【讨论】：
您可以为每个命名空间添加文件夹到您的解决方案中。虽然它仍会编译为单个可执行文件，但它会组织您的源文件并提供（我认为是）所需的效果？
我通常为我的项目中的每个命名空间添加一个文件夹，并根据相同的层次结构嵌套它们（例如 MyApp.View.Dialogs）
【讨论】：