【问题标题】:Singleton Unity Container单例 Unity 容器
【发布时间】:2013-08-14 02:50:11
【问题描述】:

我刚刚开始了解 IOC 统一框架。我在 MSDN 上阅读了几篇文章和视频。我很了解这种统一的东西是如何运作的。

1.创建容器。
2.注册你的接口/类。
3.解决你的课程。

我认为步骤 1,2 应该针对每个项目进行抽象。创建创建容器并注册接口/类的单例类是否是个好主意,以便统一容器在整个项目中可供我解决。请指教。

【问题讨论】:

  • 您正在构建什么类型的应用程序?有状态(WindowsService、WinForms、WPF)还是无状态(Web、WCF)?
  • 它是一个桌面 WPF 应用程序。
  • 这个问题基于错误的前提给出了正确的结论。有一个容器是好的。在整个项目中让那个容器“可用”真的很糟糕。后者允许将容器用作Service Locator,应尽可能避免。

标签: c# wpf inversion-of-control unity-container ioc-container


【解决方案1】:

不要使用单例。它鼓励您到处调用 resolve,这是众所周知的 DI 反模式。

相反,在您的应用程序(桌面应用程序中的主要功能,您的网络应用程序中的应用程序启动功能)中有一个点,您可以使用容器来解析您的对象图并从那里开始。

查看Mark Seeman's discussion of "Composition Root"了解更多详情。

【讨论】:

    【解决方案2】:

    使用单例。在我目前的公司中,我们在 Unity 容器周围使用单例包装器:

    • 当然是单身
    • 公开最重要的功能(如注册和解析)
    • 从 web.config/app.config 获取其配置
    • 但也可以在运行时提供(例如,用于单元测试)
    • 具有在解析过程中出现意外错误时进行默认处理的功能

    它的作用就像一个魅力,让你很容易专注于重要的事情。

    【讨论】:

      【解决方案3】:

      除了极少数情况外,您应该始终为整个应用程序(应用程序域)拥有一个容器实例。 DI 容器是线程安全的,并针对该场景进行了优化。拥有多个容器可能会导致性能问题并可能导致维护问题,因为有些场景很难实现(例如拥有应用程序范围的对象)。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2011-10-02
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多