代码之家  ›  专栏  ›  技术社区  ›  Andrew

需要参数的对象的依赖注入

  •  8
  • Andrew  · 技术社区  · 14 年前

    我们的所有报告都是从从域对象转换而来的对象图创建的。为了实现这一点,我们为每个报表都有一个translator类,并且一直在使用依赖注入传递依赖项。

    这样做效果很好,而且会产生如下结构的好类:

    public class CheckTranslator : ICheckTranslator
    {
       public CheckTranslator (IEmployeeService empSvc
                             , IPaycheckService paySvc)
       {
          _empSvc = empSvc;
          _paySvc = paySvc;
       }
    
       public Check CreateCheck()
       {
          //do the translation...
       }
    }
    

    但是,在某些情况下,映射有许多不同的分组选项。因此,c-tor将变成类依赖项和参数的混合体。

    public class CheckTranslator : ICheckTranslator
    {
       public CheckTranslator (IEmployeeService empSvc
                             , IPaycheckService paySvc
                             , bool doTranslateStubData
                             , bool doAttachLogo)
       {
          _empSvc = empSvc;
          _paySvc = paySvc;
          _doTranslateStubData = doTranslateStubData;
          _doAttachLogo = doAttachLogo;
       }
    
       public Check CreateCheck()
       {
          //do the translation...
       }
    }  
    

    现在,我们仍然可以测试它,但它不再真正适用于ioc容器,至少是以一种干净的方式。另外,如果每次检查的设置不同,我们不能再调用createcheck两次。

    虽然我认识到这是个问题,但我不一定能找到正确的解决办法。为每一类创建一个工厂似乎有点奇怪…还是这是最好的方法?

    1 回复  |  直到 14 年前
        1
  •  13
  •   Aaronaught    14 年前

    在黑暗中拍摄,但是你能把这些参数移到方法中吗?

    换句话说:

    public Check CreateCheck(bool doTranslateStubData, bool doAttachLogo)
    {
       //do the translation...
    }
    

    做那些参数 通过构造函数传入?

    (注意-如果您对此的响应是“有太多方法使其不实用”,那么问题的一部分可能是抽象太粗糙)。


    另一种选择(如果不了解域模型和注入模式,很难说)是引入一个参数对象,该对象本身由注入器管理:

    public interface ICheckConfiguration
    {
        bool AttachLogo { get; }
        bool TranslateStubData { get; }
    }
    

    然后将其与构造函数一起注入:

    public CheckTranslator (IEmployeeService empSvc, IPaycheckService paySvc,
        ICheckConfiguration config)
    {
        // etc.
    }   
    

    这个 应该 够了。然后你可以创建一个混凝土 CheckConfiguration 那两个人的班级 bool 属性,并配置容器以基于更高级别的DI参数创建参数对象(接口)的不同实例。


    我想我不应该提到的是,仅仅因为你在使用di并不意味着 一切 必须由容器管理。创造并不是一件坏事 CheckTranslator 如果只有一种“翻译器”,则以特殊方式创建对象。只要译者还依赖 抽象化 ,它在这里会这样做,那么也许您根本不应该注入它,只需要让更高级别的支持di的类创建它们。