Существует ли многоуровневый подход к внедрению зависимости / инверсии контроля

Question

DI / IOC: существует очень много фреймворков, и примеры быстро привязываются к деталям, специфичным для этой фреймворк Я нахожу, что часто лучше всего изучаю новую технологию, если могу изучать ее принципы вне рамок (леса, скрывающие деревья).

Мой вопрос: каковы простые принципы DI / IOC? Я ищу (не зависящий от структуры) подход к построению, который описывает то, что получено, какие варианты, каковы затраты, для каждого простого принципа. Пожалуйста, не просто вставляйте ссылки, если они не отвечают на мой вопрос. Я продолжаю теряться в тех лесах;}

Второй вопрос: Как только я пойму основные принципы, стоило бы построить свою собственную простую структуру? IE, будет ли полученное понимание ценным по отношению к затраченным усилиям?

Заранее спасибо! Роберт

Answer 1

Мой очень быстрый и грязный взгляд на это

• Внедрение зависимостей и инверсия управления - это не одно и то же. Инверсия управления использует DI.

• IoC - это способ объединить ваше приложение во время выполнения, а не во время компиляции.

• Вместо «обновления» типа в коде он вводится во время выполнения контейнером IoC.

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

Вот очень простой пример

Допустим, у вас есть интерфейс IEmailer для отправки писем:

public interface IEmailer
{
    void SendEmail();
}

И у вас есть хотя бы одна реализация этого интерфейса:

public class IainsEmailer : IEmailer
{
    public void SendEmail()
    {
        // Send email
    }
}

Вы определяете в конфигурационном файле контейнера IoC (каким-то образом):

IainsEmailer is my choice for IEmailer

Тогда в вашем коде вы можете получить следующее, и контейнер IoC внедрит IainsEmailer в любой конструктор, которому нужен IEmailer.

public class MyClass
{
    private IEmailer _emailer;

    public MyClass(IEmailer emailer)
    {
        _emailer = emailer
    }

    // You can now use emailer as if you have created it
    _emailer.SendEmail();
}

Я мог бы продолжить. И вкл. Но это в самом деле вся идея IoC в двух словах.

Answer 2

Это несколько устаревший, но хороший обзор Инверсия управления

Для меня основополагающими принципами, определяющими Ioc, являются понятия компонентов, модульности, слабой связи, сплоченности. Это означает, что вы разрабатываете программное обеспечение, которое разбито на связные, модульные блоки с четкими зависимостями или ссылки на другие блоки. Это основной принцип проектирования в любой области, а не только в программировании. Когда у вас есть модульность, для создания функциональной системы вам нужен способ связать эти компоненты, чтобы они образовали функциональное целое. Фреймворки IoC / DI - это компоненты, которые абстрагируют эту концепцию связывания и позволяют писать код, который объявляет связи между компонентами, а затем имеет возможность выполнять эти ссылки. Часть «инверсии» происходит из-за того, что сами компоненты больше не связываются со своими зависимостями, а связывание выполняется снаружи связующим компонентом. Это, в свою очередь, называется внедрением зависимости. Типичная структура IoC / DI позволяет вам писать код, который определяет конкретную реализацию интерфейса, от которого зависит другой компонент, а затем позволяет создавать экземпляр этого компонента, и при создании требуемая реализация будет предоставлена ​​контейнером IoC. Это затем абстрагирует концепцию создания объекта.

Answer 3

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

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

Это позволяет вам писать классы, которые:

1. Отделен от своих зависимостей.
2. Лучше сосредоточиться на их фактической ответственности (а не на их зависимости)
3. Может быть изменено через конфигурацию без перекомпиляции.
4. Легче тестируется.
5. Возможно, лучше разработан.

Чтобы ответить на ваш второй вопрос: если вы пытаетесь узнать о DI, тогда написание каркаса самостоятельно явно излишне. Я бы порекомендовал вам выбрать одну из популярных платформ с открытым исходным кодом и написать код, который ее использует - у большинства есть хорошие учебные пособия именно для этой цели.

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

Удачи! Urig

PS - Если вы находитесь в .net, не начинайте с MEF. Начните с Виндзора, Unity или Spring.Net. MEF - это больше и меньше, чем DI-фреймворк, поэтому оставим его чуть позже.