2016-04-21 2 views
0

Под «окружающим объектом» я имею в виду тот, который всегда присутствует, делая что-то в фоновом режиме, но об этом никто больше не знает. Например, объект, который подключается к событиям на множестве других объектов и регистрирует сообщения при их запуске.Как заставить зарегистрированный «окружающий» объект быть разрешенным?

Проблема заключается в том, что никто, кроме строителя Unity, не знает, что этот объект существует, никто не решает его, и он никогда не создается. Есть ли элегантное решение этой проблемы?

я мог бы создать фиктивный класс следующим образом:

public class AmbientObject 
{ 
    public object TheObject { get; set; } 
} 

создать фабричные методы, которые возвращают внешние условия внутри AmbientObject оберток для каждого случая, зарегистрировать их все с Unity, а затем корень композиции сделать container.ResolveAll<AmbientObject>() (и игнорировать возвращаемое значение), просто чтобы убедиться, что все они созданы, но это не совсем элегантно.

+0

Какую платформу вы используете? MVC, консоль WPF и т. Д.? Можете ли вы использовать OWIN? – smoksnes

+0

@smoksnes Это WPF – dlf

+0

Когда вы хотите, чтобы он был создан? Когда другие объекты разрешены или во время запуска? – smoksnes

ответ

1

Звучит так, что вы хотите, чтобы Unity автоматически разрешала ваш экземпляр в фоновом режиме.

Там, наверное, много способов сделать это, но я могу думать о двух:

1. ли это при создании контейнера с ленивым.

public static class IocContainer 
{ 

    private IMyAmbient _ambient; 
    private static readonly Lazy<IUnityContainer> Container = new Lazy<IUnityContainer>(() => 
    { 
     var container = new UnityContainer(); 

     // Do your registration. 
     container.RegisterType<IMyAmbient, Ambient>(); 
     _ambient = container.Resolve<IMyAmbient>(); 
     _ambient.DoStuff(); 
     return container; 
    }); 

    public static IUnityContainer Instance 
    { 
     get { return Container.Value; } 
    } 
} 

2. Зарегистрировать UnityContainerExtension.

public static class IocContainer 
{ 
    private static readonly Lazy<IUnityContainer> Container = new Lazy<IUnityContainer>(() => 
    { 
     var container = new UnityContainer() 
      .AddNewExtension<AmbientCreation>(); 
     container.RegisterType<IMyAmbient, Ambient>(); 
     return container; 
    }); 

    public static IUnityContainer Instance 
    { 
     get { return Container.Value; } 
    } 
} 

public class AmbientCreation: UnityContainerExtension 
{ 

    protected override void Initialize() 
    { 
     // Using PreCreation, but you may want another one? 
     Context.Strategies.AddNew<AmbientCreationStrategy>(UnityBuildStage.PreCreation); 
    } 
} 

public class AmbientCreationStrategy: BuilderStrategy 
{ 

    private IUnityContainer GetUnityFromBuildContext(IBuilderContext context) 
    { 
     var lifetime = context.Policies.Get<ILifetimePolicy>(NamedTypeBuildKey.Make<IUnityContainer>()); 
     return lifetime.GetValue() as IUnityContainer; 
    } 

    public override void PreBuildUp(IBuilderContext context) 
    { 
     // Runs at every resolve. Now you can decide when to create your ambient object. 
    } 
} 

Я использую позже для создания лог-объектов на основе стека. Может быть, это может привести вас в правильном направлении? Недостатком обоих вариантов является то, что магии вообще не происходит. Он просто перемещает логику в другую часть приложения. И можно утверждать, что BuildStrategies не должны использоваться для этого.

Подробнее: http://weblogs.asp.net/ricardoperes/unity-part-10-custom-build-strategies

 Смежные вопросы

  • Нет связанных вопросов^_^