ASP.NET MVC3 Ручное кодирование IoC

Question

Ninject, Sprint.NET, Unity, Autofac, Castle.Windsor - все это примеры, которые доступны в рамках IoC. Однако мне нравится кривая обучения и контроль над написанием моих собственных. Это, безусловно, обычная практика, чтобы не «изобретать колесо» и просто использовать ранее существовавшие структуры. Если ваш комментарий идет по этим строкам, будьте осторожны.

Могут ли IoC быть реализованы без использования XML? Мне кажется, что большинство, если не все, из вышеупомянутых фреймворков используют XML, но я бы скорее просто написал мой на C# вместо использования XML для загрузки .dll. В любом случае C# все конвертируется в один .dll.

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

Это выполняется на C#, используя библиотеку Microsoft. System.ComponentModel.IContainer, имея класс, который наследует ее. Класс, такой как Product, будет иметь интерфейс IProduct. Генерирующий конструктор затем наследовал бы от IContainer и конструктора, разрешал бы передавать репозиторий, инстанцируемый объект, который должен быть передан, и функцию, которая должна быть передана. Это позволило бы управлять действием контроллера, чтобы затем создать интерфейс (IProduct), создайте экземпляр генератора с текущим экземпляром репозитория, а затем передайте ему интерфейс и функцию.

Является ли эта настройка точной?

Я все еще пытаюсь узнать больше об этой теме и прочитал статьи wiki о IoC, DI и прочитал о Castle.Windsor, ninject, Unity и просмотрел несколько определений из MSDN в отношении библиотек C#, которые являются используемый. Любая помощь, исправления или предложения приветствуются. Спасибо

Answer 1

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

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

Тем не менее, когда вы делаете все это правильно (что очень важно для практики), у вас все равно будет одна часть вашего приложения, которая, несмотря на все ваши усилия, будет более сложной и сложной в обслуживании, поскольку приложение растет. Это часть приложения, в которой вы связываете все зависимости вместе: Composition Root.

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

Цель в DI контейнер должен сохранить корневой состав ремонтопригодным.

Хотя вы можете написать свой собственный контейнер простого DI телеграфировать вашу зависимость, чтобы предотвратить свой состав корень, чтобы стать большим хрупким, постоянно меняется шаром грязи, контейнер должен по крайней мере, одну важной особенности: Автоматическая Constructor Инъекция (ака-авто-проводка). При автоматической проводке контейнер будет рассматривать аргументы конструктора типа, который он должен создать, и он будет вставлять в него зависимости в зависимости от типов этих аргументов. Эта особенность сделает разницу между кошмаром обслуживания и здоровым корнем композиции. Хотя создание собственного контейнера, поддерживающего автоматическую проводку, не так сложно (с деревьями выражений требуется около 20 строк кода), то, как вы начинаете, требуется автоматическая проводка, это время, чтобы начать использовать одну из существующих инфраструктур DI.

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

Answer 2

Сначала я предложил бы использовать существующий контейнер для хранения данных, чтобы понять, как он работает с точки зрения конечного пользователя. Затем вы можете переделать колесо. Мое любимое высказывание: «Вы должны знать правила, прежде чем сможете их разбить».

Некоторые из того, что вы сказали, не имеют большого смысла. вам не нужно использовать System.ComponentModel.IContainer в любых фрахтовых операциях, о которых я знаю. Возможно, Unity требует этого (контейнер Microsoft), но никто из других не делает этого. Я не знаком с Unity thogh.

Answer 3

Может ли IoC быть реализован без использования XML?

Да, Ninject, Unity, Castle Windsor и Autofac могут быть настроены без использования каких-либо XML вообще. (Не уверен Spring.NET, последний раз, когда я использовал это было невозможно, версия 1.3)

В моем понимании, если не прав, поправьте, IoC может использоваться с DI, чтобы функциональность классов основываться от их определения и реализации , при этом допускается разделение .

Если под «IoC» вы имеете в виду «IoC контейнер», то да, он может быть использован с DI, но так как DI является частным случаем Инверсия управления ваш контейнер IoC будет просто контейнер для вас зависимостей. Просто имея это, ваша воля не будет волшебным образом получать любые типы, дружественные к DI. Это просто поддержка управления зависимыми зависимыми зависимостями.

Редактировать

Как Mystere Man указал в своем ответе вы должны улучшить вас понимание контейнеров IoC. Поэтому я бы рекомендовал прочитать это wonderful book (от Mark Seeman) обо всем этом.