为什么类型不取决于其包含名称空间的类型

Question

也发布了此处，但没有真正的学术答案：为什么名称空间类型不应依赖嵌套名称空间类型？

如果我正确理解它，则重点是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.
    }
}

但是，我想扩展问题。

1. 在哪里可以找到支持信息来支持此准则？
2. 为什么这种不好的做法？
3. 使类型的类型取决于来自其他包含名称空间的其他名称空间的类型？(例如，Product.Business.Security取决于Product.Business.Modules中的类型？

从某种意义上说，违反了此准则会产生一种圆形的命名空间依赖性，但我想了解更多的为什么本指南的为什么，而不仅仅是毛毯语句。我唯一能够找到的其他信息是来自链接的MSDN文章。这实际上可以大大改变类库的架构和布局。

Answer 1

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

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

使新组装引用原始Company.Data并继续进行是微不足道的。公司中的课程将继续进行，好像什么都没有改变。但是，如果他们对包含的命名空间和/或其类有依赖性，那么这样做会破坏company.data。它将打败分开关注的目的。这意味着如果他们制作了支持MySQL的产品，Company.Data.MySql将对Company.Data.SqlServer。

。

诸如提供商模型设计模式之类的技术将不再可能或可行。