Чи існує шаблон для ініціалізації об'єктів, створених через контейнер DI

Я намагаюся змусити Unity керувати створенням моїх об'єктів, і я хочу мати параметри ініціалізації, які не відомі до часу виконання:

На даний момент єдиний спосіб, коли я міг би придумати спосіб, як це зробити, це мати метод Init в інтерфейсі.

interface IMyIntf {
  void Initialize(string runTimeParam);
  string RunTimeParam { get; }
}

Тоді для його використання (в Єдності) я би зробив це:

var IMyIntf = unityContainer.Resolve<IMyIntf>();
IMyIntf.Initialize("somevalue");

У цьому сценарії runTimeParamпараметр визначається під час виконання на основі введення користувача. Тривіальний випадок тут просто повертає значення, runTimeParamале насправді параметр буде чимось на зразок імені файлу, і метод ініціалізації буде щось робити з файлом.

Це створює ряд питань, а саме те, що Initializeметод доступний в інтерфейсі і його можна викликати кілька разів. Встановлення прапора в реалізації та викидання виключення при повторному виклику Initializeздається способом незграбним.

У той момент, коли я вирішую свій інтерфейс, я не хочу нічого знати про реалізацію IMyIntf. Однак я хочу знати, що цей інтерфейс потребує певних параметрів одноразової ініціалізації. Чи є спосіб якось анотувати (атрибути?) Інтерфейс з цією інформацією та передати їх у рамки, коли об’єкт створений?

Редагувати: Описаний інтерфейс трохи більше.

Будь-яке місце, де вам потрібно значення часу виконання для побудови певної залежності, абстрактний завод - це рішення.

Після ініціалізації методів на інтерфейсах пахне витікаючою абстракцією .

У вашому випадку я б сказав, що ви повинні моделювати IMyIntfінтерфейс щодо того, як потрібно ним користуватися, а не як ви збираєтеся створювати його реалізацію. Це деталізація реалізації.

Таким чином, інтерфейс повинен бути просто:

public interface IMyIntf
{
    string RunTimeParam { get; }
}

Тепер визначте абстрактну фабрику:

public interface IMyIntfFactory
{
    IMyIntf Create(string runTimeParam);
}

Тепер ви можете створити конкретну реалізацію, IMyIntfFactoryяка створює конкретні екземпляри на IMyIntfзразок цього:

public class MyIntf : IMyIntf
{
    private readonly string runTimeParam;

    public MyIntf(string runTimeParam)
    {
        if(runTimeParam == null)
        {
            throw new ArgumentNullException("runTimeParam");
        }

        this.runTimeParam = runTimeParam;
    }

    public string RunTimeParam
    {
        get { return this.runTimeParam; }
    }
}

Зверніть увагу, як це дозволяє нам захистити інваріанти класу за допомогою readonlyключового слова. Ніяких смердючих методів ініціалізації не потрібно.

IMyIntfFactoryРеалізація може бути настільки ж простим , як це:

public class MyIntfFactory : IMyIntfFactory
{
    public IMyIntf Create(string runTimeParam)
    {
        return new MyIntf(runTimeParam);
    }
}

У всіх своїх споживачів, де вам потрібен IMyIntfекземпляр, ви просто приймаєте залежність IMyIntfFactory, запитуючи це через інжекцію конструктора .

Будь-який контейнер DI, вартий його солі, зможе автоматично надати вам IMyIntfFactoryпримірник, якщо ви зареєструєте його правильно.

Зазвичай, коли ви стикаєтеся з цією ситуацією, вам потрібно переглянути свій дизайн і визначити, чи змішуєте ви об'єкти стану / даних з вашими чистими послугами. У більшості (не всіх) випадках ви хочете, щоб ці два типи об'єктів були окремими.

Якщо вам потрібен контекстний параметр, переданий у конструкторі, одним із варіантів є створення фабрики, яка вирішує ваші сервісні залежності через конструктор і приймає параметр часу виконання як параметр методу Create () (або Generate ( ), Build () або будь-яке, що ви називаєте фабричні методи).

Як правило, налаштування або метод Initialize () вважаються поганим дизайном, тому що вам потрібно "пам’ятати", щоб викликати їх і переконатися, що вони не відкривають занадто багато стану вашої реалізації (тобто що потрібно зупинити когось -виклик ініціалізації або встановлення?).

Я також кілька разів стикався з цією ситуацією в середовищах, де я динамічно створюю об’єкти ViewModel на основі об'єктів Model (окреслені дуже добре цим іншим повідомленням Stackoverflow ).

Мені сподобалось, як розширення Ninject, яке дозволяє динамічно створювати фабрики на основі інтерфейсів:

Bind<IMyFactory>().ToFactory();

Я не зміг знайти подібну функціональність безпосередньо в Unity ; тому я написав власне розширення до IUnityContainer, яке дозволяє реєструвати фабрики, які створюватимуть нові об’єкти на основі даних із існуючих об'єктів, по суті відображаючи від ієрархії одного типу до ієрархії іншого типу: UnityMappingFactory @ GitHub

З метою простоти та читабельності я закінчив розширення, яке дозволяє безпосередньо вказати відображення без оголошення окремих заводських класів чи інтерфейсів (заставка в реальному часі). Ви просто додаєте відображення прямо там, де ви реєструєте класи під час звичайного процесу завантаження ...

//make sure to register the output...
container.RegisterType<IImageWidgetViewModel, ImageWidgetViewModel>();
container.RegisterType<ITextWidgetViewModel, TextWidgetViewModel>();

//define the mapping between different class hierarchies...
container.RegisterFactory<IWidget, IWidgetViewModel>()
.AddMap<IImageWidget, IImageWidgetViewModel>()
.AddMap<ITextWidget, ITextWidgetViewModel>();

Тоді ви просто оголосите відображення заводського інтерфейсу в конструкторі для CI і використовуєте його метод Create () ...

public ImageWidgetViewModel(IImageWidget widget, IAnotherDependency d) { }

public TextWidgetViewModel(ITextWidget widget) { }

public ContainerViewModel(object data, IFactory<IWidget, IWidgetViewModel> factory)
{
    IList<IWidgetViewModel> children = new List<IWidgetViewModel>();
    foreach (IWidget w in data.Widgets)
        children.Add(factory.Create(w));
}

В якості додаткового бонусу будь-які додаткові залежності в конструкторі відображених класів також будуть вирішені під час створення об'єкта.

Очевидно, що це не вирішить будь-яку проблему, але вона мені досить добре послужила, тому я подумав, що я повинен її поділити. Більше документації на сайті проекту на GitHub.

Я не можу відповісти конкретною термінологією Unity, але це здається, що ви тільки дізнаєтесь про введення залежності. Якщо це так, я закликаю вас прочитати короткий, зрозумілий та інформаційний посібник користувача для Ninject .

Це допоможе вам ознайомитись з різними варіантами, які ви маєте при використанні DI, і про те, як враховувати конкретні проблеми, з якими ви будете стикатися на цьому шляху. У вашому випадку ви, швидше за все, хочете використовувати контейнер DI для екземпляру своїх об'єктів, і щоб цей об'єкт отримав посилання на кожну його залежність через конструктор.

У докладному описі також детально описано, як анотувати методи, властивості та навіть параметри, використовуючи атрибути для їх розрізнення під час виконання.

Навіть якщо ви не використовуєте Ninject, покрокова інструкція дасть вам поняття та термінологію функціоналу, який відповідає вашим цілям, і ви зможете відобразити ці знання в Unity або інші рамки DI (або переконати вас спробувати Ninject) .

Я думаю, що я вирішив це, і він відчуває себе досить корисним, тому він повинен бути наполовину правильним :))

Я розділився IMyIntfна інтерфейси "getter" та "setter". Так:

interface IMyIntf {
  string RunTimeParam { get; }
}


interface IMyIntfSetter {
  void Initialize(string runTimeParam);
  IMyIntf MyIntf {get; }
}

Потім реалізація:

class MyIntfImpl : IMyIntf, IMyIntfSetter {
  string _runTimeParam;

  void Initialize(string runTimeParam) {
    _runTimeParam = runTimeParam;
  }

  string RunTimeParam { get; }

  IMyIntf MyIntf {get {return this;} }
}

//Unity configuration:
//Only the setter is mapped to the implementation.
container.RegisterType<IMyIntfSetter, MyIntfImpl>();
//To retrieve an instance of IMyIntf:
//1. create the setter
IMyIntfSetter setter = container.Resolve<IMyIntfSetter>();
//2. Init it
setter.Initialize("someparam");
//3. Use the IMyIntf accessor
IMyIntf intf = setter.MyIntf;

IMyIntfSetter.Initialize()все ще можна називати кілька разів, але, використовуючи біти парадигми локатора сервісів, ми можемо завершити її досить непогано, так що IMyIntfSetterце майже внутрішній інтерфейс, який відрізняється від IMyIntf.