【问题标题】:IoC and managing interfacesIoC 和管理接口
【发布时间】:2011-03-21 21:56:29
【问题描述】:

假设我有一个使用 IoC 实现数据访问库的业务对象库。我应该在哪里定义数据访问接口?它属于哪个图书馆?还是应该在单独的库中仅用于接口?

【问题讨论】:

    标签: interface ioc-container decoupling


    【解决方案1】:

    我会在业务领域内定义接口。然后接口的实现将在一个引用业务域的库中(并且被任何应用程序上下文引用,或者被应用程序上下文引用的 IoC 库引用)。

    然后将一个实现与另一个交换出来只是创建另一个库并在应用程序上下文中交换引用的问题。

    在 .NET 项目结构中,它看起来像这样:

    领域逻辑项目
    (没有参考)
    领域模型
    存储库接口
    IoC 服务定位器接口
    存储库项目
    (参考领域逻辑项目)
    存储库实现
    国际奥委会项目
    (参考领域逻辑项目)
    (参考资料库项目)
    IoC 服务定位器实现
    IoC 引导
    应用项目
    (参考 IoC 项目)
    (参考领域逻辑项目)
    (可能需要参考Repository Project,不确定)
    实现与领域模型交互的 UI

    【讨论】:

    • 如果存储库实现被两个不同的库使用怎么办?这是否意味着两个引用、两个接口?
    • @g.foley:除了 IoC 容器之外,还有什么需要引用存储库实现?一切都会引用域逻辑(接口)和代码。然后任何给定的应用程序上下文都将引用域逻辑和 IoC 来调用引导程序以将其全部连接起来。
    • @g.foley:或者你的意思是有两个域逻辑项目,一个存储库项目实现了两个存储库?在这种情况下,引用两者应该不是问题。但它可能会导致任何给定的应用程序上下文都携带两个域的 DLL,如果它只需要一个的话。但是大部分逻辑应该在不相互引用的域中。所以一般来说你应该很好,你只需要跟随 DLLs。
    • @g.foley:存储库实现可以引用和实现他们想要的所有接口,现在我对它进行了更多描述。事实上,没有什么能阻止您拥有一个巨大的实现类,该类实现您拥有的每个域中的所有存储库接口。这有点傻,但这是允许的。关注点的抽象和分离在接口中。实施不太重要,因为它应该是一次性/可更换的。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2011-02-05
    • 2013-10-25
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多