我的背景主要是作为Java开发人员，但最近我一直在.NET中进行一些工作。因此，我一直在尝试在家中做一些简单的项目，以更好地使用.NET。我已经能够将我的大部分Java经验转移到使用.NET(特别是C＃)中，但是真正困扰我的是名称空间。

我知道名称空间与Java包相似，但是据我所知，主要区别在于Java包使用实际的文件夹显示分隔，而在.NET中则不，所有文件都位于单个文件夹中并且名称空间仅在每个类中声明。

我觉得这很奇怪，因为我一直将软件包视为组织和组合相关代码的一种方式，从而使浏览和理解变得更加容易。由于在.NET中，这种方式无法正常工作，因此超时工作会使项目显得人满为患，而且导航也不那么容易。

我在这里想念什么吗？我必须这样。我应该将事情分解成解决方案中的单独项目吗？还是有更好的方法将类和文件保持在项目中？

编辑：正如布莱尔指出的，这几乎是在这里问的相同问题。

解决方案

回答

我不能说这是最佳实践，但是我经常看到文件以反映名称空间的目录层次结构组织。如果它更适合代码思维模式，那么我认为没有什么害处。仅仅因为.NET模型没有在名称空间，项目和目录结构之间强制执行关系，并不意味着我们就无法拥有这样的关系。

我不愿意将代码分解成比我们需要的更多的项目，因为这会减慢编译速度，并在我们必须管理多个程序集时增加一些开销。

编辑：请注意，此问题几乎是解决方案中的文件夹应与名称空间匹配的重复项？

回答

我们可以将文件夹添加到解决方案中的每个名称空间。尽管它仍然可以编译为单个可执行文件，但是它可以组织源文件并提供(我认为是)期望的效果？

我通常为项目中的每个命名空间添加一个文件夹，并根据相同的层次结构嵌套它们(例如MyApp.View.Dialogs)。

回答

VS解决方案通常包含一个或者多个项目。这些项目具有默认的名称空间(通常，名称空间只是项目的名称)。通常，如果在项目中添加文件夹，则其中的所有类将按以下方式命名：

DefaultNamespace.FolderName.ClassName

当然，我们可以更改项目的默认名称空间，并以所需的任何方式命名类。

至于何时/如何将内容分解为项目，这是经验和/或者偏好的问题。但是，我们应该绝对将解决方案中的内容分解成多个项目，以保持项目的井井有条。如果管理过多的程序集变得很麻烦(如Blair所建议的那样)，则我们随时可以将程序集合并为一个程序集。 ILMerge的优点是，即使最终只用一个程序集，所有类仍保留其原始的完全限定名称。

同样重要的是要记住，VS解决方案与代码无关。他们没有被建造。 VS解决方案不过是对项目进行分组的一种方法。正是这些项目已构建并转化为DLL。

最后，VS让我们在解决方案中的任何位置添加"虚拟"文件夹。这些文件夹未映射到文件系统中的文件夹，而只是用作组织解决方案中的项目和其他工件的另一种方式。

回答

是的，.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的设计方式和原因。

回答

命名空间纯粹是语义上的。尽管它们通常确实反映了文件夹结构，但至少在使用Visual Studio IDE时，它们并不需要。

我们可以在多个库中引用相同的名称空间，但很难做到。

回答

实际上，.Net环境允许我们将代码像意大利面条一样放在IDE /文件系统上扔在墙上。

但是，这并不意味着该方法是理智的。坚持前面提到的project.foldername.Class方法通常是一个好主意。将所有类从一个名称空间保留到同一类中也是一个好主意。

在Java中，我们可以像这样做一些棘手的事情，并获得所需的所有"灵活性"，但是这些工具会强烈建议不要这样做。坦率地说，在被介绍给.Net世界时，对我而言最令人困惑的事情之一就是，由于相对较差的指导，这可能会多么草率/不一致。不过，只需稍加思考，即可轻松理智地组织事情。 :)

回答

我一直认为源文件的组织和为类和对象分配标识符是两个单独的问题。我倾向于将相关的类放在组中，但不是每个组都应该是一个名称空间。存在(或者多或者少)命名空间来解决诸如C之类的平面命名空间语言中的名称冲突问题，我们不能走过两脚而不会绊倒诸如" mycompany_getcurrentdate"或者" MYCGetCurrentDate"之类的标识符，因为存在与另一个函数冲突的风险第三方(或者系统)库中的文件要小得多。如果为每个逻辑分隔创建一个包或者名称空间，则会得到(Java示例)类名，例如java.lang.primitivewrapper.numeric.Integer，这几乎是过大了。

回答

命名空间是逻辑分组，而项目是物理分组。

为什么这很重要？考虑一下.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命名空间与Java包无关。

.net命名空间仅用于管理声明性作用域，与文件，项目或者其位置无关。

这很简单，当
我们在该名称空间中包含"使用"。

非常简单。

名称的选择以及是否/有多少个"。"我们使用的分隔符完全取决于我们。

VS默认将.foldernames添加到命名空间中只是为了尝试并有所帮助。

本文很好地解释了名称空间：
http://www.blackwasp.co.uk/Namespaces.aspx

最后，还有一个命名约定示例，尽管名字约定是要求！ ;)

就是说，我工作过的大多数地方以及工作过的人都以明智的公司名称开头，因为这使该公司的类型名称与众不同(与其他公司，库，供应商，开源项目等分开)