IoC и ASP.NET MVC, где все это начинается?

Ответ 1

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

Недавно у меня была реальная встреча с этим. У нас есть одна существующая платежная система, а затем мы разрабатываем новую платежную систему для присоединения к PCI. Что вы делаете в такой ситуации, так это то, что вы извлекаете общие функции обеих систем в интерфейсе, а затем ваше приложение взаимодействует с этими двумя системами только через интерфейс. Вы можете использовать флаг в файле конфигурации или шаблоне factory или, в конечном счете, структуру IoC, чтобы внедрить эту зависимость в ваше приложение. Во время выполнения ваше приложение получит объект, от которого это зависит. Вам необходимо DI/IoC в среде, где существует неопределенность в отношении использования какой-либо данной подсистемы по какой-либо причине. В этом примере новая платежная система не могла своевременно доставляться, и поэтому моему приложению нужна настраиваемая опция для переключения между любой системой во время выполнения. Если я не буду делать IoC, мне придется менять код каждый раз, когда бизнес меняет свое мнение.

Еще одна необходимость IoC - сделать TDD. То же самое, что я описал выше, можно использовать для разработки макетной реализации реального приложения и может использоваться для тестирования, пока реальный компонент все еще находится в разработке.

Зависимость впрыска - хорошая книга для начала. Вы также можете скачать бесплатную бумагу на DI от того же автора здесь.

Обновление: добавление кода для большей ясности

public interface ITest
    {
        void Hello();
    }

Теперь у меня могут быть две различные конкретные реализации:

public class Hi : ITest
    {
        public void Hello()
        {
            HttpContext.Current.Response.Write("Hi there!");
        }
    }

    public class HelloMessage : ITest
    {
        public void Hello()
        {
            HttpContext.Current.Response.Write("Hello there!");
        }
    }


ITest messenger;

if (User Needs "Hi")
{
   messenger = new Hi();
}
else if (User Needs "Hello")
{
   messenger = new HelloMessage();
}

messenger.Hello(); 

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

Ниже приведен код, в котором я использую Unity 2 и аутсорсинг явной обработки зависимостей самостоятельно.

using (IUnityContainer container = new UnityContainer())
            {
                container.LoadConfiguration();

                ITest messenger = container.Resolve<ITest>();

                messenger.Hello();
            }

Конфигурация для этого же:

<unity xmlns="http://schemas.microsoft.com/practices/2010/unity">
  <assembly name="Injection"/>
  <container>
    <register type="Injection.ITest" mapTo="Injection.Hi"/>
  </container>
</unity>

НТН

Ответ 2

Для некоторых видеороликов посмотрите DimeCasts.net.

Основные две причины, по которым мне нравится Ioc:

• Простое тестирование модулей.
• Легче обменивать данные бэкэнд для тестирования. Скажем, у вас есть IPersonRepository. Ваш код реализует PersonRepository, который загружает данные из базы данных. Но что, если у вас нет данных в базе данных или база данных еще не настроена? Вы используете IoC для реализации DummyPersonRepository, который будет загружать данные из другого места, например XML файл или жестко закодированные данные.

Ответ 3

Посмотрите бесплатное видео "Инъекция зависимостей и инверсия управления" в http://tekpub.com/channels/free

Ответ 4

Я попросил что-то подобное некоторое время назад, некоторые хорошие ответы там в Примеры контейнеров IoC

Ответ 5

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

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

Эта ссылка содержит сведения о принципах SOLID, ваш вопрос, в частности, относится к "D" (принцип инверсии зависимостей), но другие будут также представляют интерес.