Вопросы о IOC

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

  1. Я использую Ninject; какой слой я должен положить dll Ninject
  2. Когда я создаю настройку для отправки клиенту, dll Ninject также отправляются клиенту?
  3. Я изучал интернет и пришел к следующему выводу: а. Инверсия управления — это когда я изменил свои классы и не инстансирую их внутри своего класса, а передаю в качестве параметров или использую такие инструменты, как Ninject b. Внедрение зависимостей — это когда я добавляю в свой проект интерфейсы, а не конкретные классы.

dependency-injection c# layer ioc-container ninject
person ridermansb    schedule 18.02.2011    source источник

Ответы (3)


arrow_upward
1
arrow_downward

Объявление2. Вы должны добавить DLL-файлы ninject в свою настройку.

Объявление3. Инверсия управления (IoC) не имеет ничего общего с интерфейсами и классами. У вас может быть сильно связанный код с инверсией управления.

class GodClass
{
    void DoSth(int param)
    {
        switch (param)
        {
           case 0: Console.WriteLine("param is 0"); break;
           case 1: Console.WriteLine("param is 1"); break;
        }
    }
}

а с IoC это может выглядеть так:

class GoodClass
{
     Dictionary<int, BaseClass> _consoleWriters;

     public GoodClass( IEnumerable<BaseClass> writers )
     {
         foreach (var writer in writers) 
            _consoleWriters.Add( writer.ParamSupported, writer);
     }
     void DoSth(int param)
     {
         _consoleWriters[ param ].DoSth();
     }
}

abstract class BaseClass
{
    abstract int ParamSupported {get;}
    abstract void DoSth(int param);
}

class ZeroWriter : BaseClass
{
     override int ParamSupported {get{return 0;}}
     override DoSth(int param) { Console.WriteLine("param is 0"); }
}

class OneWriter : BaseClass
{
     override int ParamSupported {get{return 1;}}
     override DoSth(int param) { Console.WriteLine("param is 1"); }
}

Объявление1. Я бы добавил конфигурацию/инициализацию инфраструктуры IoC в основную функцию и передал ссылку на инициализированный контейнер в остальную часть кода.

person dzendras    schedule 18.02.2011

arrow_upward
2
arrow_downward

  1. Концепция IoC ортогональна концепции архитектурных уровней. Вам придется ссылаться на Ninject (а) всякий раз, когда вы используете функции Ninject, такие как атрибут [Inject] (обычно на уровне внедренных классов) или (б) везде, где вы настраиваете ядра и модули (обычно на уровне клиента).

  2. да. Ninject станет зависимостью вашей среды выполнения.

  3. IoC может представлять такое поведение, но его основную концепцию лучше понимать как принцип Голливуда. : не звоните нам, мы позвоним вам. Это означает, что не утруждайте себя настройкой своих зависимостей, потому что они будут предоставлены вам. Вы можете добиться этого многими способами, даже «вручную», хотя такие инструменты, как Ninject, могут значительно облегчить вашу жизнь. В любом случае, получение объектов зависимостей по параметру (в основном во время создания объекта) является очень распространенным шаблоном, поскольку он определяет зависимости через интерфейсы, а не через классы.

Использование интерфейсов может помочь вам установить контракты, чтобы лучше отделить требования от реализаций (что в первую очередь является движущей причиной применения IoC). Кроме того, это может помочь вам в написании тестов и моков. Но это другая вселенная возможностей. Развлекайся! Я использую Ninject уже почти год, и я нашел его очень простым в использовании и обслуживании.

person Humberto    schedule 18.02.2011

arrow_upward
0
arrow_downward

  1. У вас должна быть ссылка на Ninject, где бы вы ни использовали его для регистрации и разрешения своих зависимостей. Наиболее очевидным местом для этого является оболочка вашего приложения/точка входа.
  2. да

  3. О внедрении зависимостей... В зависимости от того, на каком языке вы говорите, это может быть неправдой. В случае C#/VB.NET да. В динамических языках, таких как JavaScript, Ruby и т. д., не очень. Я предполагаю, что в настоящее время это также может быть неправильно с C #, если вы используете DynamicObject. Указав, что ваш класс зависит от интерфейса, а не от конкретного класса, вы можете легко внедрить другую реализацию этого интерфейса либо вручную, либо с помощью контейнера IoC, такого как Ninject.

    Об инверсии управления... Это в основном говорит о том, что вместо того, чтобы вызывающий класс/метод создавал, какие другие компоненты ему нужны для выполнения своей работы, пусть он будет создан где-то еще и передан вашему классу/методу. Разрыв этой конкретной цепочки зависимостей сделает ваш код более слабо связанным и позволит вам заменить одну реализацию требуемого компонента другим компонентом, реализующим тот же интерфейс/контракт.

    Отличное объяснение принципа инверсии зависимостей / IOC можно найти в http://www.objectmentor.com/resources/articles/dip.pdf.

    Другие хорошие ресурсы по этой теме:

person Jimmy Chandra    schedule 18.02.2011