我的背景主要是作为Java开发人员，但最近我一直在.NET中做一些工作。所以我一直试图在家里做一些简单的项目，以更好地使用.NET。我已经能够将我的大部分Java经验转移到.NET（特别是C＃）中，但唯一让我感到困惑的是名称空间。.NET命名空间
我知道命名空间与Java软件包相似，但是从我所知道的主要区别在于，对于Java软件包，它们使用实际的文件夹来显示分隔，而在.NET中并不存在所有文件在一个文件夹中，并且在每个类中只声明名称空间。
我觉得这很奇怪，因为我总是看到软件包是一种组织和分组相关代码的方式，使得它更易于浏览和理解。因为在.NET中，这种方式不适用于这种工作，加班，项目显得更加拥挤并且不容易导航。
我在这里错过了什么吗？我必须。我应该在解决方案中将事情分解成单独的项目吗？还是有更好的方法来保持项目中组织的类和文件？
编辑：正如布莱尔指出，这是几乎相同的问题here问。
我不能说这是一个最佳实践，但我经常看到文件组织在一个目录层次结构中，该目录层次结构反映了命名空间。如果它更适合你的代码的心智模型，那就这么做 - 我想不出有什么伤害。仅仅因为.NET模型不强制名称空间，项目和目录结构之间的关系并不意味着如果你愿意，你不能拥有这样的关系。
如果你需要管理多个程序集，这可能会减慢编译速度并增加一点开销，所以我会对将代码分解为比你需要的更多项目有点谨慎。
编辑：请注意，这个问题是近的should the folders in a solution match the namespace?
重复您可以将文件夹添加到您的每个命名空间的解决方案。虽然它仍然会编译为单个可执行文件，但它会组织源文件并提供（我认为的）所需的效果？
我通常添加一个文件夹在我的项目每个命名空间，其嵌套根据同一层次（MyApp.View.Dialogs例如）
一个VS解决方案通常包含一个或多个项目。这些项目有默认的命名空间（通常命名空间只是项目的名称）。通常情况下，如果你的项目中添加一个文件夹，在它所有的类将被命名如下：
DefaultNamespace.FolderName.ClassName
当然，你可以改变项目的默认命名空间，并且以任何你想要的方式命名你的类。
至于何时/如何将东西分解为项目，这是一个经验和/或偏好问题。但是，为了保持项目的组织性，您绝对应该在解决方案中将项目分解成项目。如果管理太多组件变得麻烦（正如布莱尔建议的那样），您可以将您的组件集中到一个组件中。ILMerge最棒的地方在于，即使最终只有一个程序集，您的所有类仍保留其原始的完全限定名称。
记住VS解决方案对代码没有影响也很重要，他们没有建立。 VS解决方案不过是组合项目的一种方式;它是构建并转化为DLL的项目。
最后，VS让我们在解决方案的任何位置添加“虚拟”文件夹。这些文件夹不会映射到文件系统中的文件夹，而只是用作帮助您在解决方案中组织项目和其他工件的另一种手段。
是的，在.NET命名空间不依赖于文件系统或其他任何东西。我认为这是一个很大的优势。例如，您可以将代码拆分到允许灵活分发的不同程序集中。
在Visual Studio中工作时，当您将新文件夹添加到项目树时，IDE倾向于引入新的名称空间。
下面是从MSDN一个有用的链接：
命名的命名空间 的一般规则是使用公司名称，后跟 技术名称和可选的 功能和设计如下。
CompanyName.TechnologyName [.Feature] [设计]
当然你也可以在你找到更适合的方式使用的命名空间。但是，如果你要分享你的代码，我会建议遵循公认的标准。
编辑：
我强烈推荐任何.NET开发人员获得的Framework design guidelines副本这本书将帮助您了解如何和为什么.NET设计。
CompnayName.Technology向您购买什么？以这种方式命名事物我看不出任何好处。任何见解？ – 2008-09-11 04:17:50
您是否阅读过MSDN文章？事实上，当第二方第三方程序集使用相同的根名称空间时，我有这种情况。 – aku 2008-09-11 07:41:11
命名空间纯粹是语义。虽然他们通常会反映文件夹结构，但至少在使用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
它也有一个例子命名朝端约定，虽然你的名字约定是您的来电！ ;）
说，我工作过的大多数地方和我一起工作过的人都从公司名称开始，这是明智的，因为它使该公司的typenames与众不同，（与其他，库，供应商，开源projcts等）
对不起，但我保证我做了搜索之前，我问，只是显然不是正确的事情。 – 2008-09-11 02:48:47