考虑一个基于组件的系统，其中组件使用彼此的功能并且可能具有软循环依赖关系。这里的“软依赖”是指一个依赖组件将使用另一个可用的服务，但如果没有它，它仍然可以运行属性。系统中也存在硬依赖，当一个组件没有另一个组件就无法运行，但它们不是循环的。这是一个好的设计还是应该避免循环依赖，即使它们是软的？
这个问题源于 C# 不允许项目在项目之间具有循环依赖关系，我使用项目来隔离系统中的组件。然后它们被编译成程序集，其中的一个子集由应用程序根据配置动态加载。
PS如果您将此问题标记为不具建设性，请添加评论，建议我可以在其中提出设计问题，这些问题并不总是有一个客观的答案并且需要一些讨论。
更新：请求的软依赖示例：客户端管理器组件需要使用位置组件的服务，告诉客户端对象的位置（这是硬依赖，因为客户端必须知道对象的位置）。然而，位置组件也希望使用客户端管理器组件的接口来扩展客户端的 API 并允许他们设置位置（这是软依赖），因为如果当前实例的系统中可能不存在客户端管理器组件服务器不需要与客户端交谈。
从您在更新中提供的示例中，我将根据静态（而不是hard）和动态（而不是soft）依赖项来表达您的需求。
ClientImpl如果静态使用LocationImpl并LocationImpl动态使用ClientImpl（通过 a ClientInterface） ，我不会将其视为设计问题。ClientImpl甚至可以LocationImpl通过LocationImpl将 aClientInterface作为参数的方法注入自身。这构成了一种相当广泛采用的面向对象模式（称为控制注入或依赖注入，其背后的哲学是相同的，请参阅Martin Fowler近十年前写的关于它的内容）。
顺便说一句，所有这一切都意味着它ClientImpl的级别比LocationImpl它的级别更高ClientInterface。
当设计文档将循环依赖称为主要设计问题时，它通常指的是静态/硬依赖。
这个问题源于 C# 不允许项目在项目之间具有循环依赖关系，我使用项目来隔离系统中的组件。
事实上，因为如果两个程序集相互引用，那么很有可能会创建一个静态/硬依赖关系。MS 一直将程序集视为实现组件概念的 .NET 方式，因此 VS 防止了组件之间的循环依赖。
有趣的是，.NET Framework 设计带有几个循环程序集依赖项！
