c# - 为什么 C# 中的命名空间允许循环依赖?

标签 c# namespaces circular-dependency circular-reference

在 c# 中,您可以在文件 a.cs(具有 MyApp.A 的命名空间)中包含一条语句:

using MyApp.B;

而文件 b.cs(具有 MyApp.B 的命名空间)已经有语句

using MyApp.A;

如果不同的 dll 中存在类似的依赖关系(其中 a.dll 引用 b.dll,反之亦然),由于循环依赖错误,它不会被允许,那么为什么命名空间(和编译器)允许它甚至不产生警告)?这样做不是有代码味道吗?

最佳答案

Damien_The_Unbeliever 写道命名空间是功能的逻辑分组

Hans Passat 写道,Namespace is nothing but a simple hint to the compiler

我想详细说明一下,这实际上取决于您将什么视为代码库中的组件组件 是一组类型。 组件 可以生成一个或多个在一个或多个程序集中定义的命名空间。重要的是组件之间没有依赖循环。因为一个组件是一个开发单元,如果组件A和B互相使用,就构成了一个更大的开发单元,它们不能独立开发,它们形成一个 super 组件,或者换句话说,这是意大利面条代码的根。

要回答您的问题,为什么 C# 中的命名空间允许循环依赖?您问题背后的隐式声明是命名空间用于定义逻辑组件。但命名空间也可用于避免类型名称冲突,以结构化方式呈现公共(public) API 的类,过滤一组扩展方法......因此我猜答案是 C# 设计者肯定没有'不想仅仅为了逻辑组件化而限制命名空间的概念

附带说明一下,许多开发人员使用项目/程序集 的概念来定义组件。恕我直言,这是错误的,因为装配是一个物理概念,伴随着成本和维护(版本控制、部署、编译、动态 CLR 加载……)。出于物理的原因(例如部署单元、API 单元、插件实现、代码/测试分离...),应该将程序集作为一个物理 概念使用。我写了two white books关于这个程序集与命名空间与组件主题,如果您感兴趣的话。


这样做不是代码味道吗?

在我看来是的,因为如果一个大型程序集包含许多具有依赖循环的 namespace ,则无法尝试从代码中理解整体架构。我在一个名为 NDepend 的 .NET 静态分析器上工作,它可以检查 namespaces dependency cycles并通过 dependency graph 呈现结果和 dependency matrix .我们有 400 多个命名空间,我们很高兴将它们正确地分层放置在十几个程序集中。依赖矩阵提供了一种方便的方式来一目了然地可视化分层命名空间结构。

NDepend Dependency Matrix

关于c# - 为什么 C# 中的命名空间允许循环依赖?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/37829263/

相关文章:

circular-dependency - 在 JSON 模式中检查循环依赖的任何工具

c# - 客户端 ID 在哪个页面生命周期生成?

c++ - 是否可以将函数声明放在未命名的命名空间中?

java - Java构造函数中的循环依赖

c++ - 请帮助我使用 C++ 命名空间

ruby-on-rails - 带命名空间的 Rails 3 路由

angular - ionic 应用程序中的循环依赖

c# - 如何在 MVC5 网站中创建基于时间的事件?

c# - 在 C# 中从 Window 服务启动应用程序

c# - 获取点击控件的点