Сочетание внедрения зависимостей и динамического ткачества - PullRequest
Новая
       29

Сочетание внедрения зависимостей и динамического ткачества

3 голосов
/ 10 ноября 2011

Для DI я использую Microsoft Unity. Для динамического Aspect Weaving я использую Rapier-LOOM.

Специалист по аспектам требует от меня создания экземпляров тканых объектов, используя фабричный метод Weaver.CreateInstance(System.Type), и не предоставляет средств для переплетения существующего экземпляра.

Контейнер DI позволяет мне разрешать зависимости с помощью метода IUnityContainer.Resolve(System.Type), который разрешает зависимость, а также создает экземпляр объекта внедренного типа.

Эти два подхода явно противоречат друг другу. Каков рекомендуемый способ разрешения этого конфликта?

Идеи, которые у меня были до сих пор:

  • Запросить сопоставление и «вручную разрешить» зависимость (используя свойство IUnityContainer.Registrations). Создайте комбинированный механизм «DI + AOP», который, учитывая тип для разрешения, находит целевой сопоставленный тип, а затем создает его с помощью Weaver.
  • Создайте мою собственную реализацию интерфейса IUnityContainer, который создает экземпляр с использованием Weaver (вместо Activator)

приписка

Если я не в курсе, и конфликта можно было бы избежать, а не разрешить, - пожалуйста, дайте мне знать.

Ответы [ 3 ]

2 голосов
/ 12 ноября 2011

Я не знаком с Rapier-LOOM, поэтому я просто буду говорить с точки зрения Unity. Есть пара подходов различной способности / сложности. К счастью, ни один из них не предполагает повторной реализации IUnityContainer.

Самое простое, что вы можете сделать, - это зарегистрировать типы, которые вы хотите создать через ткача с использованием InjectionFactory. Это позволяет вам указать делегата, который будет выполняться для создания экземпляра вместо поведения по умолчанию. Примерно так: 

  container.RegisterType<ISomething>(
    new InjectionFactory(c => {
        var newObject = (Something)Weaver.CreateInstance(typeof(Something));
        newObject.Property1 = c.Resolve<TypeOfProperty1>();
        newObject.Property2 = c.Resolve<TypeofProperty2>();
        return newObject;
    });

Затем при вызове container.Resolve () этот делегат будет запущен.

Второй подход заключается в создании расширения Unity, которое подключается в вызове Weaver.CreateInstance к цепочке создания. Вы можете использовать собственную стратегию в основной цепочке стратегий или попробовать переопределить план сборки. С первым гораздо проще.

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

2 голосов
/ 10 ноября 2011

Взгляд на страницу кодового сплетения LOOM не предоставляет никаких функций, которые невозможно сделать с помощью перехвата метода Unity. Начните читать здесь: Аспектно-ориентированное программирование, Перехват и Unity 2.0

1 голос
/ 11 марта 2012

это плохой аргумент. Это то же самое, если я скажу, что Microsoft Unity не предоставляет никаких функций, которые нельзя сделать с помощью .NET-framework. Вопрос в том, какая модель программирования лучше всего подходит для моей задачи. Ответом может быть количество кода, необходимого для реализации требований. AOP, особенно Rapier-LOOM.NET, не является простым средством создания метода. Целью АОП является инкапсуляция сквозных проблем. Для этого вам нужны советы, введения, переменные точек соединения, аннотации на основе кода и т. Д. Если я хочу реализовать больше, чем простой пример трассировки, вам нужны более мощные концепции, чем начало метода.

...