我面临着使用像下面这样的工厂方法来影响基于 setter 的 DI 的前景(因为 Entity Framework 阻止我使用基于构造函数的 DI)。因此,当一个对象在 EF 中具体化时,我调用下面的方法来执行 setter 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 注入(inject),那么在第 20 位进行类型检查的任何一种都需要 20 倍的时间来检查第一种类型检查,因为每次在 EF 中具体化一个对象时我都会这样做,所以它可能不会缩放。
所以我正在寻找更好的算法。以前的“解决方案”只是在关联对象的构造函数中分配适当的 KeyHolder,如下所示:
public FeeType()
{
this.KeyHolder = new FeeTypeKeyHolder();
}
这似乎仍然是运行时效率最高的解决方案,而且我仍然非常倾向于不考虑可测试性,因为基于 DI 的潜在大量效果 setter 可能会与上述工厂方法一起使用。我真的很可能会解耦这些类,但不会以牺牲此 Web 应用程序的可伸缩性为代价。
最佳答案
你可以用你的属性标记你需要通过 DI 设置的属性,比如 [Inject]
,然后在需要的地方(比如构造函数)调用辅助方法比如 MyHelper.InjectProperties(this )
。在 helper 中,您可以使用 [Inject] 获取属性并直接从构造函数解析它们的值。
大多数 IoC/DI 框架都以高效的方式支持属性注入(inject),因此在最好的情况下,您不需要自己实现它。
关于c# - 高效判断类型,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/24349003/