【问题标题】:IWindsorInstaller in an assembly and resolving local dependencies程序集中的 IWindsorInstaller 并解析本地依赖项
【发布时间】:2011-10-04 22:39:33
【问题描述】:

我有一个具有模型和服务程序集的 WPF MVVM 应用程序。我正在尝试弄清楚如何使用 Windsor 容器来解决本地(服务层中的服务)依赖项,但我唯一能弄清楚的事情是笨拙且不正确。

服务安装程序:

public class ServicesInstaller : IWindsorInstaller
{
    public void Install(IWindsorContainer container, IConfigurationStore store)
    {
        //Services
        container.Register(
            Component.For<IServiceA>().ImplementedBy<ServiceA>().LifeStyle.Singleton,
            Component.For<IServiceB>().ImplementedBy<ServiceB>().LifeStyle.Singleton
    }
}

服务消费者(位于服务中):

public class ServiceConsumer
{
     public SomeMethodThatUsesServiceAOnlyOcassionally()
     {
         //buncha logic.
         if (allThatFailed)
         {
                 ??? ResolveServiceA ???
         }
     }
} 

因为我不经常依赖 ServiceA,所以我不想通过构造函数注入或属性注入来传递它。我会向安装程序添加一个静态容器实例,但我必须相信还有比这更惯用的解决方案。

【问题讨论】:

    标签: c# dependency-injection castle-windsor


    【解决方案1】:

    你想要的是常见的 DI 模式。

    如果你的服务有一个可选的依赖(换句话说,它可以在没有依赖的情况下做它的事情),你应该使用属性注入。如果您的服务需要该依赖项才能正常工作,则应使用构造函数注入(因为它是必需的依赖项)。但是,如果创建该服务很耗时,则应将该依赖项隐藏在代理后面,这样可以在第一次调用代理时懒惰地创建该依赖项。

    但是,在您的情况下,ServiceA 被注册为单例,因此它仅在应用程序的生命周期内创建一次。换句话说,没有理由使用代理,并且由于您的服务没有它就无法生存,您应该只使用构造函数注入,因为这清楚地表明IServiceA 是必需的依赖项。

    【讨论】:

    • 那么就没有理由以编程方式解析类型(除了初始化/接线)?
    • @Ritch:如果您想手动调用容器(在应用程序逻辑内部)来解析实例?没有永不!这将导致Service Locator anti-pattern
    • 好的,服务定位器是我的一个习惯。我明白了,但它很容易默认旧思想。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2016-12-25
    • 2012-04-14
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2014-06-09
    相关资源
    最近更新 更多