为什么一个类型不应该依赖于其包含命名空间的类型？答案

【问题标题】：Why should a type not depend on types from its containing namespace?为什么一个类型不应该依赖于其包含命名空间的类型？
【发布时间】：2017-06-22 20:32:34
【问题描述】：

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

如果我理解正确的话，重点是Product.Business.Modules.Module 类型可以依赖于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 取决于 Product.Business.Modules 中的类型？

从某种意义上说，违反本指南会产生一种循环命名空间依赖关系，但我想更多地了解本指南的为什么，而不仅仅是笼统的陈述。我能找到的唯一其他信息来自链接的 Msdn 文章。这实际上可以显着改变类库的架构和布局。

【问题讨论】：

标签： c# namespaces design-guidelines

【解决方案1】：

首先，我将解决您的第三个问题。我没有看到任何反对这一点的建议，这似乎是一件合理的事情。您在逻辑上分隔命名空间，代码的一个分支可能会使用另一个分支。

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

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

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

【讨论】：