Вопросы по IoC - PullRequest
       56

Вопросы по IoC

2 голосов
/ 18 февраля 2011

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

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

Ответы [ 3 ]

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

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

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

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

1 голос
/ 18 февраля 2011

Ad2.Вы должны добавить в свои настройки недействительные dll.

Ad3.Инверсия управления (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"); }
}

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

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

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

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

    Другие полезные ресурсы по этой теме:

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...