棱镜和圆形依赖答案

【问题标题】：Prism and Circular Dependence棱镜和圆形依赖
【发布时间】：2011-02-03 14:52:49
【问题描述】：

我必须棱镜模块，这些模块都依赖于其他提供的服务。有没有办法以安全的方式呈现相互依存关系？我曾考虑将它们组合成一个模块，但它们在逻辑上确实不合逻辑。

顺便说一句，我知道 MEF 可以做到这一点；我知道MEF很棒！我爱MEF。我无法切换到该技术，因为它需要升级框架和 IDE，而我现在（时间方面）负担不起。

如果您遇到和我一样的问题，请查看MEF。对我来说太晚了；自救！

【问题讨论】：

标签： wpf prism circular-dependency

【解决方案1】：

在我看来，合乎逻辑的解决方案是将这两个模块之间共享的服务提取到第三个模块中。你的两个当前模块可以安全地依赖于共享模块，你没有循环依赖和一个很好的分离项目结构。

有什么理由不能这样做？

【讨论】：

逻辑上这些是非常原子的模块。也就是说，它们各自提供单一服务。我很擅长分解，也许太好了，也许我应该把它们组合起来，但这在逻辑上是丑陋的。但我认为它很实用。一种是超时服务，在一定的空闲时间后重新启动信息亭应用程序，另一种是视图切换/导航服务。

【解决方案2】：

我知道该怎么做。演示服务在初始化时不需要超时服务，因此我在惰性属性中解决了它。

    public ITimeout Timeout
    {
        get
        {
            if (_timeout == null)
                _timeout = _serviceLocator.GetInstance<ITimeout>();

            return _timeout;
        }
    }

由于超时服务在其模块初始化时注册，因此该属性在需要时可用。它并不理想，但它有效。故事的寓意是MEF。

叹息！

【讨论】：

似乎这些模块是相互依赖的，它们在逻辑上应该是同一个模块。
@Anderson，模块分解并不总是最好地沿着依赖线划分。有时有必要在两个独立的实体之间建立一对一的关系。它们不是相互依赖的，因为它们都依赖于对方提供的服务，而不是对方本身提供的服务。与他们结婚将是一种方便和实用的行为，而不是逻辑。在时间限制要求我务实之前，我是一个理想主义者。谢天谢地，我有一点余地和一个同时有效的解决方案。
我还没有遇到过这样的情况：两个模块相互依赖，无法更恰当地分解（通过将有问题的服务放在另一个模块中，或者决定它们是一个基本的核心功能）进入外壳）。你的方案是什么？
@Anderson，可能是后者。