为什么类型不依赖于包含命名空间的类型？

Question

也张贴在这里，但没有真正的学术答案： why namespace types should not depend on nested namespaces types?

如果我理解正确，关键是Product.Business.Product类型可以依赖于Product，而不是相反，因为Module是namespace Product.Business { using Modules; class Product { public IEnumerable<Module> Modules { get; } // Module is abstract, with many different kinds defined in Modules. } } 的基础}。但是，看看我的项目结构，我违反了这个准则：

Product.Business.Security

但是，我想提出这个问题。

1. 我在哪里可以找到支持该指南的支持信息？
2. 为什么这是不好的做法？
3. 类型是否依赖于具有相同包含名称空间的其他名称空间的类型是否有效？ （例如Product.Business.Modules取决于{{1}}？
中的类型

在某种意义上，违反此指南会产生一种循环的名称空间依赖关系，但我想更多地了解本指南的 why ，而不仅仅是一个全面的声明。我能找到的唯一其他信息来自链接的Msdn文章。这实际上可以显着改变类库的体系结构和布局。

Answer 1

首先，我将解决您的第3个问题。我没有看到任何反对的建议，似乎是一个合理的事情。您可以逻辑地分隔名称空间，并且代码的一个分支可能会使用另一个分支。

但是，在嵌套命名空间时，您正在创建层次结构。作为一个假设的例子，考虑一家公司正在测试他们正在开发的一些数据工具：Company.Data将具有Company.Data.SqlServer将依赖的抽象类和基类。 SqlServer为包含的命名空间中的抽象内容提供特定的实现。由于反馈或需要支持另一个数据库系统，可能的时候，为了可维护性，他们决定将SqlServer类移到另一个库中。

让新程序集引用原始Company.Data并继续下去是微不足道的。 Company.Data中的类将继续进行，就像没有任何更改一样。但是，如果它们依赖于包含的命名空间和/或其类，那么这样做会破坏Company.Data。它将打败分离问题的目的。这意味着如果他们制作支持MySQL的产品，Company.Data.MySql将依赖Company.Data.SqlServer。

Provider Model design Pattern等技术将不再可行或不可行。