Внедрение IoC вручную с помощью службы Windows - PullRequest
Новая
       0

Внедрение IoC вручную с помощью службы Windows

6 голосов
/ 26 июля 2011

Я новичок в IoC и поэтому следую примерам, приведенным Джеффри Палермо в его сообщениях на http://jeffreypalermo.com/blog/the-onion-architecture-part-1/ и в его книге, размещенной здесь https://github.com/jeffreypalermo/mvc2inaction/tree/master/manuscript/Chapter23

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

Однако я создаю службу Windows, а не веб-приложение ASP.NET MVC, поэтому я немного заболелвниз на части запуска.В частности, в файле web.config он регистрирует реализацию IHttpModule ВНУТРИ инфраструктурного проекта в качестве модуля запуска, а затем использует событие после сборки, чтобы скопировать необходимые библиотеки в каталог веб-сайта, чтобы обойти прямую зависимость в самом веб-проекте.

Я не думаю, что у меня есть такой тип роскоши в настоящей службе Windows, поэтому как мне добиться чего-то похожего, если у меня небольшой стартовый проект, который зависит как от инфраструктуры, так и от ядра, илиЕсть ли другой способ обойти ограничения во время компиляции службы Windows?

Заранее спасибо.

Ответы [ 2 ]

3 голосов
/ 26 июля 2011

Основываясь на тегах этого вопроса (c #), я предполагаю, что вы внедрите Службу Windows, основываясь на ServiceBase . Если это так, метод OnStart будет вашим Composition Root - именно здесь вы будете составлять граф объектов приложения. После того, как вы скомпилировали граф объектов, композиция закончена, и скомпонован граф объектов.

В OnStop вы можете снова списать граф объектов.

Ничто не мешает вам реализовать различные компоненты графа разрешенных объектов в отдельных сборках. Вот что я бы сделал.

1 голос
/ 27 июля 2011

Я думаю, вы неправильно поняли роль фреймворка IoC.

Чтобы ответить на ваш вопрос

но разве ссылка не подразумевает зависимость?

Да, но на другом уровне.IoC о зависимостях между классами.Вместо использования new Something() в вашем классе вы предоставляете конструктор, который требует всех зависимых интерфейсов.Таким образом, класс не контролирует, какая реализация ему передана.Это инверсия контроля.Контейнер IoC - это просто средство, помогающее управлять зависимостями приятным способом.

Допустим, у вас есть интерфейс ICustomerNotificationService с реализацией, подобной 

public class MailNotificationService : INotificationService
{
    IMailerService _mailer;
    ICustomerRepository _customerRepo;
    IOrderRepository _orderRepo;

    public MailNotificationService(IMailerService mailer, 
                                   ICustomerRepository customerRepo, 
                                   IOrderRepository oderRepo)
    {
        // set fields...
    }

    public void Notify(int customerId, int productId)
    {
        // load customer and order, format mail and send.
    }
}

Так что, если ваше приложение запрашиваетэкземпляр ICustomerNotificationServcie контейнер выясняет, какие конкретные реализации взять и пытается удовлетворить все зависимости, которые имеет запрошенный класс.

Преимущество состоит в том, что вы можете легко настроить все зависимости в логике начальной загрузки и иметь возможность изменятьповедение вашего приложения очень легко.

Например, при тестировании вы запускаете приложение с реализацией IMailerService, которая записывает почту в файл, а в рабочем режиме подключается настоящая почтовая служба.Это было бы невозможно, если бы вы обновились, скажем, MailerService в своем конструкторе вместо того, чтобы принимать его в качестве параметра.

Хороший контейнер IoC может обрабатывать гораздо больше, для вас как управление временем жизни, одиночками, сканированием сборокдля типов вы хотите зарегистрироваться и многое другое.Мы основали всю нашу систему плагинов на Структурной карте , например.

Вы можете взглянуть на эту статью блога и вторую часть .

...