Что такое IOC? Нужны некоторые практические примеры кода для иллюстрирования

Имейте чтение этого превосходного статья от Martin Fowler.

кроме того, смотрите на , Внедрение зависимости статьи .

Википедии является самым известным примером инверсии управления, который в коротких поворотах Ваш код от этого:

public class FileReader { }
public class Application {
    // inflexible concrete dependency
    private FileReader fileReader = new FileReader(); 
}

К:

public interface Reader {}
public class FileReader implements Reader {}
public class Application {
    // flexible abstract dependency injected in
    private Reader reader;

    public Application(Reader reader) { // constructor injection
        this.reader = reader;
    }
    public void setReader(Reader reader) { // setter injection
        this.reader = reader;
    }
}

IOC или инверсия управления, в большинстве приложений, инвертируя маршрут через код от UI до базы данных. Эта СИ не полный ответ, но это - один из самых легких способов получить Вашу голову вокруг понятия.

, Если Вы хотите изучить IOC, войдите в TDD, поскольку Вы найдете установку тестов намного легче, как только Вы инвертируете.

Пример:

Типичный поток большинства приложений.NET, которые я видел, является чем-то вроде этого:

UserCollection col = BusinessLayer.Class.GetLoggedInUsers();
//Business logic
return col;

тогда бизнес похож на это:

UserTable table = DataLayer.Class.GetLoggedInUsers();
return table;

и т.д. Это - весь псевдокод. Для использования IOC в этом примере Вы добавляете интерфейс для класса слоя данных, как IUserRepository. Можно использовать дженерики, и я рекомендовал бы под капотом.

можно тогда сделать что-то вроде этого:

IUserRepository repository = SetUpRepository();
UserCollection col = BusinessLayer.Class.GetUsers(repository);

, Почему это важно? Для тестирования можно создать ложный репозиторий и подать его к бизнес-классу. Насмешка содержит данные, которые всегда являются тем же, что означает, что Вы осуществляете свой код, не тестируя вплотную.

, Если Вы хотите C#, вот основной пример на weblogs.asp.net :

Нет, МОК не является DDD или TDD.

Martin Fowler статья является хорошим введением.

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

Для получения, почему все это полезно, Вам нужна некоторая выставка, так терпите меня.

Единственная ответственность в основном означает, что Ваш класс должен быть максимально независим от других частей системы, для уменьшения влияния изменения одной части на другом. (Можно также скрепить это к тому, что изменение реализации не должно инициировать перекомпиляцию всех файлов в проектах, как имеет место при изменении.h файлов в проекте C/C++, например). Побочный эффект состоит в том, что Вы заканчиваете с большим количеством маленьких объектов, которые делают одну вещь только, но очень хорошо (в идеальном мире)

, Но в большинстве случаев, для выполнения его работы один объект должен говорить с другим объектом: это зависит от них.

Первая часть смягчения, которое является к, разделяет реализацию от интерфейсов. Это означает полагаться на интерфейсы (или чисто абстрактные классы, в зависимости от Вашего предпочтительного языка), так, чтобы один объект не был связан с определенной реализацией другого.

Так для использования канонического примера, в бизнес-потребностях слоя, необходимо выполнить функцию, для которой нужен доступ к - слой данных для получения объектов - Некоторого другого сервиса - регистратор для входа информации и или ошибки

В свою очередь, каждый сервис или зависимость имеет свои собственные зависимости, о которых должен был бы знать класс, даже если это не использует их. В зависимости от суммы ссылок, настраивая объект может выйти из рук быстро. Теперь умножьте это на количество классов, которые необходимо записать, и Вы заканчиваете с путаницей вещей.

Используя контейнер IOC в основном помогает Вам избавиться от той путаницы. При необходимости в объекте Вы не делаете "новый он". Вместо этого Вы просите, чтобы контейнер IOC получил его для Вас. Контейнер ответственен за обеспечение функционального объекта, готов использоваться, безотносительно его зависимостей.

то, Что это означает, - то, что Вы классифицируете, не имеет никакой потребности того, чтобы быть знающим о зависимостях классов, на которые это полагается, который сокращает путаницу. Кроме того, это не должно знать, какой фактический класс реализует сервисы, на которые это полагается, что означает, что - реализация услуги может быть определена в другом проекте (dll или безотносительно), так изменение, это никогда не будет влиять на Вас класс - реализация может быть другой в зависимости от контекста (думайте об изменении базы данных или даже попытке к веб-сервису получить информацию в зависимости от конфигурации или даже текущего состояния приложения).

, Чтобы попытаться ответить на Ваши другие вопросы, IOC является шаблоном. TDD и DDD являются методологиями проектирования, поэтому нельзя приравнять другой. Но IOC является неоценимым инструментом для поддержки TDD или DDD.

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

Hope, которая помогает немного.

Для Вашего вопроса о том, каков IOC, Википедия имеет довольно обширное объяснение .

Относительно учебных руководств или примеров этот учебное руководство касается его вполне хорошо и имеет много кода экс-клена.

Если Вы понимаете DIP (Принцип Инверсии Зависимости), IOC является пирогом. Я предлагаю изучить объектно-ориентированные принципы перед изучением шаблонов. Базовые принципы могут быть сложены как legos для выполнения любого шаблона. Brandon Joyce

Инверсия управления - это абстракция логической структуры. Один из подходов (часто используемый как синоним IoC) - это внедрение зависимостей, которое абстрагирует ссылки между объектами. Когда объекты освобождаются от деталей реализации приложения, таких как какой класс реализует какую службу, они могут сосредоточиться на своих основных функциях.

Например, предположим, что у вас есть класс, которому необходимо сопоставить Foo объектам Bar . Вы можете написать это:

public class FooMapper
{
    public Bar Map(Foo foo)
    {
        // ...
    }
}

и использовать это так:

public class NeedsToMapFoos
{
    public void MapSomeFoos()
    {
        var fooMapper = new FooMapper();

        // ...
    }
}

Хотя это верно, это также жестко. NeedsToMapFoos заботится только о том, чтобы отображение происходило , а не о том, что оно происходит каким-либо определенным образом.

Мы можем представить концепцию «операции без реализации» с помощью интерфейса:

public interface IFooMapper
{
    Bar Map(Foo foo);
}

и объявить зависимость от этой операции:

public class NeedsToMapFoos
{
    private readonly IFooMapper _fooMapper;

    public NeedsToMapFoos(IFooMapper fooMapper)
    {
        _fooMapper = fooMapper;
    }

    public void MapSomeFoos()
    {
        // ...use _fooMapper...
    }
}

Теперь NeedsToMapFoos имеет меньше знаний, что означает, что он менее сложен. Вместо выполнения административных функций можно сосредоточиться на бизнес-модели.

Такие хорошо продуманные объекты также более адаптируемы. Подобно тому, как алмазы жесткие, а глина податлива, внутренняя структура определяет реакцию на изменения.

Наконец, логика, написанная в этом стиле, также гибка. Допустим, FooMapper.Map - дорогостоящая операция, и ее следует кэшировать. Вы можете использовать шаблон декоратора, чтобы обернуть существующую реализацию и беспрепятственно передать ее в NeedsToMapFoos :

public class CachingFooMapper : IFooMapper
{
    private readonly IFooMapper _innerMapper;
    private readonly IDictionary<Foo, Bar> _cache;

    public CachingFooMapper(IFooMapper innerMapper)
    {
        _innerMapper = innerMapper;
    }

    public Bar Map(Foo foo)
    {
        // Read bar from _cache. If not there, read from inner mapper and add to _cache.
    }
}

// Usage

new NeedsToMapFoos(new CachingFooMapper(new FooMapper()));