1

也发布在这里，但没有真正的学术答案： 为什么命名空间类型不应该依赖于嵌套的命名空间类型？

如果我理解正确，重点是类型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 文章。这实际上可以显着改变类库的架构和布局。

4

1 回答 1

0

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

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

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

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

于 2017-06-22T21:22:02.477 回答