我们所有的报告都是根据从我们的领域对象翻译而来的对象图创建的。为了实现这一点,我们为每个报告都有一个 Translator 类,并且一直在使用依赖注入(inject)来传递依赖项。
这很好用,并且会产生像这样结构的很好的类:
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 两次。
虽然我知道这是个问题,但我不一定能找到正确的解决方案。为每个类创建一个工厂似乎有点奇怪……或者这是最好的方法吗?
最佳答案
这里是在黑暗中拍摄的,但是您可以将这些参数移到方法中吗?
换句话说:
public Check CreateCheck(bool doTranslateStubData, bool doAttachLogo)
{
//do the translation...
}
那些参数有要通过构造函数传入吗?
(注意 - 如果您对此的回答是“有太多方法无法实用”,那么部分问题可能是抽象太粗糙)。
另一种选择(如果不了解域模型和注入(inject)模式,真的很难说)是引入一个本身由注入(inject)器管理的参数对象:
public interface ICheckConfiguration
{
bool AttachLogo { get; }
bool TranslateStubData { get; }
}
然后用构造函数注入(inject):
public CheckTranslator (IEmployeeService empSvc, IPaycheckService paySvc,
ICheckConfiguration config)
{
// etc.
}
这应该就够了。然后,您可以创建一个具体的 CheckConfiguration
类,该类在其构造函数中采用这两个 bool
属性,并配置您的容器以创建基于参数对象(接口(interface))的不同实例更高级别的 DI 参数。
我想我应该提到的最后一件事是,仅仅因为您正在使用 DI 并不意味着一切都必须由容器管理。如果只有一种“翻译器”,以临时方式创建 CheckTranslator
对象并不是一件坏事。只要翻译器仍然依赖于抽象,它在这里所做的,那么也许您根本不应该注入(inject)它,只需让更高级别的启用 DI 的类临时创建它们。
关于c# - 需要参数的对象的依赖注入(inject),我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/2573055/