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

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

25 голосов
/ 21 октября 2010

Я вижу, что "IoC" и "DI" упоминаются почти везде для ASP.NET MVC. Хотя я хорошо понимаю ... что-то вроде этого, это одна из тех почти двусмысленных, аморфных плавающих концепций, которая, кажется, либо обошла меня стороной, либо я просто не смотрю в нужном месте. В предстоящем выпуске ASP.NET MVC 3.0 я вижу это еще больше. Настолько, что создается впечатление, что это целая часть программирования, которую я просто не знаю о .

Я пытался искать книги по предметам, но большая часть того, что я нахожу, кажется, делает много предположений (история в Ruby, понимание того, что это такое, но не то, как его использовать и т. Д.).

Я просто спрашиваю заранее и ясно. Что такое IoC, и почему меня это волнует? Есть ли достойные сайты, которые освещают это с точки зрения начинающего программиста? Предположим, я ничего не знаю об этом. Предположим, я ничего не знаю, кроме C #. Я читал каждую книгу, блог и учебник по C # от .NET 1.1 до .NET 2.0, и когда вышли .NET 3.5 и LINQ, стало так много справляться, что я не мог идти в ногу. Я начинающий разработчик, работающий в ASP.NET MVC / C #, и я не могу помочь, но чувствую, что упускаю что-то очень важное. (У меня много таких же чувств к DI (инъекция зависимости))

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

StackOverflow всегда был для меня лучшим из лучших в сообществе разработчиков. Через колледж и вводную работу, а также работу на низком уровне, я объединила свое обучение программированию с другими программистами (хотя, насколько я понимаю, это не обязательно что-то, за что должно быть стыдно). Итак, еще раз, я просто заявляю сообществу.

А? Я не понимаю.

Разговаривая со многими моими коллегами, которые пытаются проникнуть в одну и ту же область, многие из них чувствуют то же самое. Так что я не могу не чувствовать, что где-то рядом, мы, «новички», программисты, пропустили памятку об этих концептуальных подходах к кодированию. Я хотел бы не только получить ответ на этот вопрос, но я думаю, что хорошей веткой для других людей, таких как я, которые пытаются понять, может быть разумная идея (и если она существует, ее нужно сделать более очевидной)

Вот что я нашел полезным: http://www.theserverside.com/news/1321158/A-beginners-guide-to-Dependency-Injection и http://www.dotnetspark.com/kb/1222-inversion-control--beginner-guide.aspx

Но мне все еще приходится чесать голову по ряду вопросов о том, почему это важно. Честно говоря, я чувствую, что значительная часть сообщества разработчиков на самом деле так относится к IoC и модульному тестированию. очень мало, что это такое , и обнаруженные примеры, как правило, довольно скудны или очень трудны для понимания. Когда был представлен .NET, он был автономным. Мне не нужно было кучу других концепций для запуска простых программ. Теперь .NET является уважаемым языком, и все под солнцем принимает его (nHibernate, MVC, MVP, MVVP, платформы Clouding, игровая архитектура и т. Д.)

(Пожалуйста, не стесняйтесь указывать, если я просто вопиюще неправ. Я ни в коем случае не называю себя «хорошим». Но я знаю C # и знаю это очень хорошо. Я считаю себя очень быстрым учеником и как В это трудное время я просто должен предположить, что есть некая «дыра», которую нужно заполнить)

Ответы [ 5 ]

12 голосов
/ 21 октября 2010

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

Недавно я столкнулся с этим в реальной жизни.У нас есть одна существующая платежная система, а затем мы разрабатываем новую платежную систему для соответствия PCI.Что вы делаете в подобных ситуациях, так это то, что вы извлекаете общие функции обеих систем в интерфейс, а затем ваше приложение взаимодействует с этими двумя системами только через интерфейс.Вы можете использовать флаг в конфигурационном файле или фабричном шаблоне или, в конечном счете, в инфраструктуре 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>

HTH

2 голосов
/ 21 октября 2010

Для некоторых видео вступлений, проверьте DimeCasts.net .

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

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

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

0 голосов
/ 01 декабря 2010

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

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

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

0 голосов
/ 21 октября 2010

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

...