我的背景主要是Java开发人员，但最近我一直在做一些.NET的工作。因此，我一直在尝试在家做一些简单的项目，以便更好地使用.NET。我已经能够将我的许多Java经验转化为使用.NET（具体来说是C#），但唯一真正困扰我的是命名空间。
我知道命名空间类似于Java包，但据我所知，主要区别在于Java包使用实际文件夹来显示分离，而在.NET中并不是这样，所有文件都驻留在单个文件夹中，并且命名空间只是在每个类中声明。
我觉得这很奇怪，因为我总是把包看作是组织和分组相关代码的一种方式，使其更容易导航和理解。由于在.NET中它不起作用，随着时间的推移，项目看起来更加拥挤，而且不容易导航。
我错过了什么吗？我必须错过了什么。我应该将事情分成解决方案中的单独项目吗？还是有更好的方法在项目中组织类和文件？
编辑：正如Blair指出的那样，这几乎是相同的问题here。
虽然我不能声称这是最佳实践，但我经常看到文件按照镜像命名空间的目录层次结构进行组织。如果这符合您对代码的思维模型，那么就这样做吧 - 我想不出有任何害处。仅因为.NET模型未强制要求命名空间、项目和目录结构之间的关系，并不意味着如果您愿意的话，就不能有这样的关系。
我会有点担心将代码分成比所需更多的项目，因为这可能会减慢编译速度，并在管理多个程序集时增加一些开销。
编辑：请注意，这个问题几乎与应该让解决方案中的文件夹与命名空间匹配吗？相同。
在.NET中，命名空间不依赖于文件系统或其他任何东西。在我看来，这是一个很大的优势。例如，您可以将代码分散到不同的程序集中，从而实现灵活的分发。
在Visual Studio中工作时，IDE会在项目树中添加新文件夹时引入新的命名空间。
这是来自MSDN的一个有用链接：
命名命名空间的一般规则是使用公司名称，后跟技术名称，可选地包括特性和设计如下。
CompanyName.TechnologyName[.Feature][.Design]
当然，您可以按照您认为更合适的方式使用命名空间。但是，如果您要分享您的代码，我建议您遵循已接受的标准。
编辑：
我强烈建议任何.NET开发人员获取框架设计准则的副本。这本书将帮助您了解.NET的设计方式和原因。
Visual Studio 解决方案通常包含一个或多个项目。这些项目有默认的命名空间（通常命名空间就是项目的名称）。通常情况下，如果你在项目中添加一个文件夹，该文件夹中的所有类都将以以下方式命名：
当然，您可以更改项目的默认名称空间，并以任何您希望的方式命名您的类。DefaultNamespace.FolderName.ClassName
您可以为每个命名空间将文件夹添加到您的解决方案中。虽然它仍将编译为单个可执行文件，但它会组织您的源代码文件并产生所需的效果（我认为是这样）。
我通常为项目中的每个命名空间添加一个文件夹，并将它们按照相同的层次结构嵌套（例如MyApp.View.Dialogs）。
命名空间是纯粹的语义化概念。虽然它们通常反映了文件夹结构，至少在使用Visual Studio IDE时如此，但并非必须如此。
同一个命名空间可以在多个库中引用，这可能会让人感到不适，但却是事实。
