FW:使用injectedProperties将同一个mapTo与不同的mapFrom进行未命名注册时出现意外结果
本文关键字:注册 未命名 结果 意外 mapFrom injectedProperties 使用 同一个 mapTo FW | 更新日期: 2023-09-27 18:24:44
当将同一个具体类注册到不同的未命名实例时,我们看到了Unity的意外行为。在这种情况下,注册似乎以意想不到的方式相互干扰。
- 我们为我们想要注入的其他应用程序提供了一个框架与可能是可以以不同方式初始化的同一类,或者具有不同的注入参数和/或不同的值。当框架通过一个接口使用类时,它可以预期与通过不同的界面。因此,我们向具有不同初始化的相同mapTo类(并且可能寿命)。当我们通过Unity中的不同接口,它们不会相互干扰另外这适用于命名实例,但不适用于未命名实例实例
- 尝试注册映射到同一类的不同接口:
- 异常:在第二次注册期间应该引发异常。只有当我们认为这是对框架的滥用时,才会出现例外;我们不相信这是真的
- 覆盖:覆盖可能是有意义的,但当前实现的内部表示似乎意味着,由于mapTo类型的参数增加,它不是为覆盖而设计的。在下面的示例代码中,我们注册了映射到同一类的2个不同接口,每个接口都注入了2个属性。我们可以看到,container.policys.policys(类型为ObjectBuilder.SpecifiedPropertiesSelectorPolicy)propertiesAndValues的值包含4个注入的属性。在覆盖的情况下,我们预计会看到2个注入的属性用第二个注册中的值初始化。如果注册了映射到同一类型的多个不同类型,并将在其中每个类型中注入一些具有值的属性,而其中一些属性没有(预计不会初始化),则此行为的结果是,解析的实例将无法正确初始化任何已注册的类型
- 独立注册:所有注册都将得到正确解决,每个注册都将注入正确的属性值
独立注册是我们所期望的,但不起作用。mapTo类型似乎不是基于注册的类型管理的,而是仅基于mapTo类型和注册的名称管理的。我们想了解预期的行为是什么,当前的行为是否是预期的,以及是否有实现独立注册的干净方法。请注意,我们已经看到了命名注册的建议,但我们不想更改我们的框架,因为它正在使用中,而且通常我们不想在没有逻辑原因的情况下强制应用程序符合命名实例。所附的代码演示了意外行为。
using System;
using Microsoft.Practices.Unity;
using Microsoft.Practices.Unity.Configuration;
namespace TestUnity
{
public interface IBaseInterface
{
string BaseString { set; get; }
}
public interface IChildInterface : IBaseInterface
{
string ChildString { set; get; }
}
public class ChildClass : IChildInterface
{
public string BaseString { set; get; }
public string ChildString { set; get; }
}
public class ContainerClass
{
public IBaseInterface impl { set; get; }
}
class Program
{
static void Main(string[] args)
{
var container = new UnityContainer();
container.LoadConfiguration();
// the expected result BaseString ="IBaseInterface_BaseString" & ChildString ="IBaseInterface_ChildString"
// the result is BaseString ="IChildInterface_BaseString" & ChildString ="IChildInterface_ChildString"
var iBaseInterface = container.Resolve<IBaseInterface>();
// the expected result BaseString ="IChildInterface_BaseString" & ChildString ="IChildInterface_ChildString"
var iChildInterface = container.Resolve<IChildInterface>();
//We expect test class will be initialize with BaseString ="IBaseInterface_BaseString" & ChildString ="IBaseInterface_ChildString"
//but the result is the expected result BaseString ="IChildInterface_BaseString" & ChildString ="IChildInterface_ChildString"
var testClass = container.Resolve<ContainerClass>("Test");
//The container.Registrations include both regestered types(IBaseInterface & IChildInterface)
foreach (var registration in container.Registrations)
{
Console.WriteLine(@"RegisteredType :{0} ,MappedToType :{1}", registration.RegisteredType, registration.MappedToType);
}
Console.ReadLine();
}
}
}
App.config
<?xml version="1.0"?>
<configuration>
<configSections>
<section name="unity" type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection, Microsoft.Practices.Unity.Configuration"/>
</configSections>
<unity xmlns="http://schemas.microsoft.com/practices/2010/unity">
<alias alias="IBaseInterface" type="TestUnity.IBaseInterface, TestUnity" />
<alias alias="IChildInterface" type="TestUnity.IChildInterface, TestUnity" />
<alias alias="transient" type="Microsoft.Practices.Unity.TransientLifetimeManager, Microsoft.Practices.Unity"/>
<container>
<register type="IBaseInterface" mapTo="TestUnity.ChildClass, TestUnity">
<lifetime type="transient"/>
<property name="BaseString" value="IBaseInterface_BaseString" />
<property name="ChildString" value="IBaseInterface_ChildString" />
</register>
<register type="IChildInterface" mapTo="TestUnity.ChildClass, TestUnity">
<lifetime type="transient" />
<property name="BaseString" value="IChildInterface_BaseString" />
<property name="ChildString" value="IChildInterface_ChildString" />
</register>
<register name="Test" type="TestUnity.ContainerClass, TestUnity" mapTo="TestUnity.ContainerClass, TestUnity">
<lifetime type="transient" />
<property name="impl" dependencyType="IBaseInterface" />
</register>
</container>
</unity>
</configuration>
TL;DR-抱歉,但这似乎是对Unity的限制。
我不是构建Unity的团队的成员,所以我只能推测预期的行为,因为它没有明确记录在这个特定的场景中。但按照Unity的其他行为的优先级,我本以为它会覆盖以前注册的InjectionProperty
。
在查找用于构建请求解析的对象实例的策略时,对象生成器没有考虑注册的类型,这是正确的。对象生成器键由mapTo类型和名称组成(请参见NamedTypeBuildKey)。这个键的创建方式是Unity的Object Builder内部不可或缺的。尝试将已注册的类型添加到管道中的该键将比您想要解决的自定义问题多得多。我想不出其他方法来介绍你想要的基于注册类型的独立注册行为(除了不同的具体类或多个命名注册)。