我的背景主要是作为Java开发人员，但最近我一直在.NET中进行一些工作。因此，我一直在尝试在家中做一些简单的项目，以更好地使用.NET。我已经能够将我的大部分Java经验转移到使用.NET(特别是C#)中，但是真正困扰我的是名称空间。
我知道名称空间与Java包相似，但据我所知，主要区别在于，对于Java包，它们使用实际的文件夹来显示分隔符，而在.NET中则不是，所有文件都位于其中。一个文件夹，然后在每个类中简单声明名称空间。
我觉得这很奇怪，因为我一直将软件包视为组织和组合相关代码的一种方式，从而使导航和理解变得更加容易。由于在.NET中，这种方式无法正常工作，因此超时工作会使项目显得人满为患，而且导航也不那么容易。
我在这里想念什么吗？我必须这样。我应该将事情分解成解决方案中的单独项目吗？还是有更好的方法来将类和文件保持在项目中？
编辑：正如布莱尔指出的那样，这几乎是这里提出的相同问题。
我不能说这是最佳实践，但是我经常看到文件以反映名称空间的目录层次结构组织。如果它更适合您的代码思维模式，那就这样做-我认为没有什么害处。仅仅因为.NET模型不强制名称空间，项目和目录结构之间的关系，并不意味着您就无法拥有这样的关系。
将代码拆分成更多的项目会有些麻烦，因为这会减慢编译速度，并在您必须管理多个程序集时增加一些开销。
编辑：请注意，此问题几乎与解决方案中的文件夹是否与名称空间匹配相重复？
是的，.NET名称空间不依赖于文件系统或其他任何内容。我认为这是一个很大的优势。例如，您可以将代码拆分为不同的程序集，从而实现灵活的分配。
在Visual Studio中工作时，将新文件夹添加到项目树时，IDE倾向于引入新的命名空间。
这是来自MSDN的有用链接：
命名空间命名准则
The general rule for naming namespaces
is to use the company name followed by
the technology name and optionally the
feature and design as follows.
CompanyName.TechnologyName[.Feature][.Design]
当然，您可以以更适合的方式使用名称空间。但是，如果您要共享代码，我建议您遵循公认的标准。
编辑：
我强烈建议任何.net开发人员获得Framework设计指南的副本。这本书将帮助您了解.NET的设计方式和原因。
命名空间是逻辑分组，而项目是物理分组。
为什么这很重要？考虑一下.NET 2.0、3.0和3.5。 .NET 3.0基本上是具有某些额外程序集的.NET 2.0，而3.5则增加了一些其他程序集。因此，例如，.NET 3.5添加了DataPager控件，它是一个Web控件，应分组在System.Web.UI.WebControls中。如果名称空间和物理位置相同，那可能不是因为它在不同的程序集中。
因此，将名称空间作为独立的逻辑实体意味着您可以将多个不同程序集的成员进行逻辑分组，因为它们是要相互结合使用的。
(而且，物理布局和逻辑布局都非常相似也没错。)
一个VS解决方案通常包含一个或多个项目。这些项目具有默认的名称空间(通常，名称空间只是项目的名称)。通常，如果在项目中添加文件夹，则该文件夹中的所有类都将按以下方式命名：
DefaultNamespace.FolderName.ClassName
当然，您可以更改项目的默认名称空间，并以您希望使用的任何方式来命名您的类。
关于何时/如何将内容分解为项目，这取决于经验和/或偏好。但是，您绝对应该将解决方案中的内容分解成多个项目，以使您的项目井井有条。如果管理过多的程序集变得很麻烦(如Blair所建议的那样)，则您随时可以将您的程序集合并为一个程序集。 ILMerge的优点在于，即使最终只用一个程序集，您的所有类仍保留其原始的完全限定名称。
切记VS解决方案与代码无关-即，也很重要。他们没有被建造。 VS解决方案不过是对项目进行分组的一种方法。这是已构建并转化为DLL的项目。
最后，VS让我们在解决方案中的任何位置添加" virtual "文件夹。这些文件夹未映射到文件系统中的文件夹，而只是用作帮助您组织解决方案中的项目和其他工件的另一种方式。
区别在于.net命名空间与Java包无关。
.net命名空间仅用于管理声明性作用域，与文件，项目或其位置无关。
非常简单，在特定名称空间中声明的所有内容在以下情况下都可以访问
您在该名称空间中包含一个" using "。
非常容易。
名称的选择以及是否使用/使用多少个'。\\'分隔符完全取决于您。
VS默认会在您的命名空间中添加.foldernames只是为了尝试并有所帮助。
本文很好地解释了名称空间：
http://www.blackwasp.co.uk/Namespaces.aspx
它的末尾还有一个示例命名约定，尽管您的名字约定是您的要求！ ;)
那是说，我工作过的大多数地方以及工作过的人都以明智的公司名称开头，因为这使该公司的类型名称与众不同((与其他公司，库，供应商，开源项目分开)等)
实际上，.Net环境允许您将代码像意大利面条一样放在IDE /文件系统上扔在墙上。
但这并不意味着这种方法是理智的。坚持前面提到的project.foldername.Class方法通常是一个好主意。将所有类从一个名称空间保留到同一类中也是一个好主意。
在Java中，您可以执行诸如此类的麻烦操作，以及获得所需的所有"灵活性"，但是这些工具会强烈建议不要这样做。坦白说，被介绍给.Net世界对我来说最令人困惑的事情之一就是，由于相对较差的指导，这可能多么马虎/前后不一致。不过，只需稍加思考，就可以很轻松地理智地组织事情。 ：)
命名空间纯粹是语义上的。尽管它们通常确实反映了文件夹结构，但至少在使用Visual Studio IDE时，它们并不需要。
您可以在多个库中引用相同的名称空间，但很难做到。
您可以为解决方案的每个名称空间添加文件夹。虽然它仍然可以编译为单个可执行文件，但是它可以组织您的源文件并提供(我认为是)所需的效果？
我通常为项目中的每个命名空间添加一个文件夹，并根据相同的层次结构嵌套它们(例如MyApp.View.Dialogs)。
我一直认为源文件的组织和为类和对象分配标识符是两个独立的问题。我倾向于将相关的类放在组中，但不是每个组都应该是一个名称空间。存在命名空间(或多或少)来解决名称冲突的问题，例如在诸如C的平面命名空间语言中，如果不绊倒诸如mycompany_getcurrentdate或MYCGetCurrentDate之类的标识符，您就不能走两英尺，因为存在与第三方(或系统)库中另一个功能的冲突要小得多。如果为每个逻辑分隔创建了一个程序包或名称空间，您将得到(Java示例)类名称，如java.lang.primitivewrapper.numeric.Integer，这几乎是多余的。
