Создание ядра Ninject в библиотеке классов
У меня есть класс, который имеет зависимости, которые я обеспечил электричеством с помощью Ninject.
public interface IFoo {}
public class MyObject {
[Inject]
IFoo myfoo;
}
В реальной реализации я использую инжекцию свойства, но только быстро проиллюстрировать, я введу на поле. Как я понимаю вместо newing экземпляров MyObject, чтобы заставить зависимости быть правильно введенными, я должен использовать
kernel.Get<MyObject>()
Вещь, на которую я натыкаюсь однако, состоит в том, что MyObject будет только использоваться в контексте библиотеки классов. Намерение состоит в том, чтобы оконечные приложения создали свои собственные модули, и передайте его в экземпляр ядра для гидратирования. Учитывая, что, каков обычно самый прагматический способ приблизиться к обработке поверхности универсального экземпляра ядра Ninject к моей библиотеке классов так, чтобы экземпляры MyObject (и другие подобные случаи) могли гидратироваться?
Мой первый наклон является своего рода фабрикой, которая усваивает одноэлементное ядро - который сами приложения должны гидратироваться/инициализировать путем загрузки модуля.
Таким образом в RandomService.cs
var myKernel = NinjaFactory.Unleash();
var myobj = myKernel.Get<MyObject>();
myobj.foo();
Прежде чем я зайду слишком далеко вниз этот путь, хотя, я должен сделать проверку работоспособности, чтобы удостовериться, что взгляды являются звуковыми или что нет некоторых очевидной другой вещи, которую я пропускаю. Я очевидно плохо знаком с МОК и чувствую себя подобно мне grok основы, но не обязательно лучший реальный мир способы использовать его.
2 ответа
Это, вероятно, более просто, чем вы думаете. Весна не делает никакой магии. Синтаксический анализатор конфигурации XML просто создает определения компонентов и регистрирует их в фабрике компонентов. То же самое можно сделать, создав DefureListureBeanFactory и зарегистрировав в нем определения компонентов. Главная ошибка здесь состоит в том, чтобы подумать: «Джи, я просто создам бобы и помещу их в контекст приложения». Этот подход не работает, потому что Spring создает бобы лениво, и API построен вокруг идеи фабрики, которая вызывается, когда это необходимо, а не фабрики, которая выполняет всю работу при запуске.
Ниже приведен пример кода . Обратите внимание, что этот образец требует гораздо больше строк кода, но, определяя собственные вспомогательные методы, вы должны иметь возможность разбить это на что-то, что должно быть наравне с XML.
Также проверьте источник для испытаний блока пружин .
-121--4012969-Рискуя показаться глупым - Вы рассматривали это как другой способ?
Лично я бы избегал пакетной обработки, которая «далека» от базы данных. Я не знаю, какую базу данных вы используете, но обычно существует механизм для эффективного извлечения набора данных из базы данных и в файл, даже если он включает умеренно простые манипуляции на выходе. Хранимые процедуры, определенные утилиты экспорта. Изучите, что еще доступно от поставщика базы данных.
-121--4817611-Я не уверен, что понимаю все детали вашего вопроса, но, насколько я понимаю, вы спрашиваете, как можно экстернализировать зависимость от Ninject.
Существует возможность записи библиотек, дружественных к DI, без ссылки на определенный контейнер DI (Ninject или что-либо еще). Это позволяет потребителю библиотеки выбрать контейнер DI по своему вкусу (или вообще не использовать контейнер). Этот подход является намного предпочтительным, поскольку он обеспечивает большую степень свободы.
Однако следует использовать Впрыск конструктора вместо Впрыск свойства . Хотя Property Injection кажется обманчиво простым в реализации, на самом деле это довольно трудно получить право.
Одно из больших преимуществ Constructor Injection состоит в том, что нет необходимости помещать какие-либо атрибуты в конструктор, поскольку он структурно уже несет всю информацию, необходимую для правильного подключения контейнера DI.
Точка зрения Марка определенно является моей отправной точкой (поэтому +1) в этом вопросе. NB не забудьте перейти по его ссылке.
В прошлом я был виновен в том, что слишком рано отказался от свойств (или полей) над конструктором (моим "оправданием" было то, что поскольку базовому классу нужно 5 свойств, я не хотел нагружать ими все производные классы. Решением этой проблемы было обернуть 5 свойств в класс или иерархию классов, представляющих любые базовые концепции, которые эти свойства представляют. Немного похоже на рефакторинг Introduce Parameter Object.
Хорошее обсуждение этих соображений я нашел полезным в http://thinkbeforecoding.com/post/2009/05/15/IOC-container-go-hide (не могу найти пост SO, в котором упоминается это и некоторые темы вокруг этого, может кто-нибудь вставит ссылку :D)
Другой блог, который суммирует некоторые из этих моментов - Your IoC Container is Showing
И http://davybrion.com/blog/2009/11/integrating-your-ioc-container-with-agatha/