不确定标题是否有意义，但这是我能想到的最好的，所以让我解释一下。我正在重构，主要是重写和简化我的解决方案中的一个项目，其中包含一堆基本上包含我的业务逻辑的“服务”。有一堆服务，每个服务都支持我的Entity Framework实现中的特定对象。我面临的问题是每个服务可能依赖于其他服务，这些服务可能依赖于其他服务以及可能的调用服务。事实上，我实际上遇到了旧版本代码中的循环依赖，我通过欺骗它并声明该类的泛型版本来解决。它有效，但我不是很喜欢它。
通过重写，我想解决循环依赖发生的可能性，但我遇到的问题是所有服务都需要将一个存储库注入其中。目前Ninject为我处理这个问题，并且在构建对象时可能会将相同的存储库注入其中，但我不确定如何维护Ninject负责所有服务的依赖关系，并以某种方式避免循环的可能性引用。
我正在寻找有关如何解决这个难题的建议。
答案 0 :(得分：0)
针对这些接口声明每个服务和程序的接口。如果对服务使用构造函数注入，则这些接口将不具有循环依赖性，因为构造函数不是接口的一部分。这些接口可以在一个单独的仅合同项目中一起声明。
实现这些服务的类仅取决于接口，而不取决于具体的服务实现。这样，项目之间就不会有循环引用。