為什么類型不依賴於包含命名空間的類型？

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

首先，我將解決您的第3個問題。 我沒有看到任何反對的建議，似乎是一個合理的事情。 您可以邏輯地分隔名稱空間，並且代碼的一個分支可能會使用另一個分支。

但是，在嵌套命名空間時，您正在創建層次結構。 作為一個假設的例子，考慮一家公司正在測試他們正在開發的一些數據工具： Company.Data將具有抽象類和Company.Data.SqlServer將依賴的基類。 SqlServer為包含的命名空間中的抽象內容提供特定的實現。 由於反饋或需要支持另一個數據庫系統，可能的時候，為了可維護性，他們決定將SqlServer類移出到不同的庫。

讓新的程序集引用原始的Company.Data並繼續下去是微不足道的。 Company.Data中的類將繼續進行，就像沒有任何更改一樣。 但是，如果它們依賴於包含的命名空間和/或其類，那么這樣做會破壞Company.Data。 它將打敗分離問題的目的。 這意味着如果他們制作產品來支持MySQL，那么Company.Data.MySql將依賴於Company.Data.SqlServer 。

諸如提供者模型設計模式之類的技術將不再可行或不可行。