我面临使用如下所示的工厂方法来实现基于setter的DI的前景(因为Entity Framework阻止我使用基于构造函数的DI)。因此,当一个对象在EF中实现时,我调用以下方法来执行设置程序DI。
public void AttachKeyHolder(ILocalizableEntity localizableEntity)
{
var ft = (localizableEntity as FeeType);
if (ft != null)
{
localizableEntity.KeyHolder = new FeeTypeKeyHolder();
return;
}
var other = (localizableEntity as OtherType);
if (other != null)
{
localizableEntity.KeyHolder = new OtherTypeKeyHolder();
return;
}
// And on and on and on for every applicable type
}
我不喜欢这样,因为这成为一个基于n的问题,如果我有20种需要此setter注入的类型,那么在第20位进行类型检查的任何一个都将花费20倍的时间作为第一个类型检查,并且我每次在EF中实现一个对象时都会这样做,它可能不会缩放。
所以我正在寻找更好的算法。先前的“解决方案”是在关联对象的构造函数中分配适当的KeyHolder,如下所示:
public FeeType()
{
this.KeyHolder = new FeeTypeKeyHolder();
}
这似乎仍然是最有效的运行时解决方案,并且无论是否具有可测试性,由于上述工厂方法,基于DI的潜在大量效果设置器,我仍然非常倾向于解决该问题。我真的很可能将这些类解耦,但不会以牺牲此Web应用程序的可伸缩性为代价。
您可以标记自己需要通过DI设置的属性,例如属性,[Inject]
然后在所需的位置(例如构造函数)调用helper方法,例如MyHelper.InjectProperties(this)
。在助手中,您可以使用[Inject]获取属性,并直接从构造函数中解析其值。
大多数IoC / DI框架都以有效的方式支持属性注入,因此在大多数情况下,您无需自己实现它。
本文收集自互联网,转载请注明来源。
如有侵权,请联系 [email protected] 删除。
我来说两句