ASP.NET MVC3 Ручное кодирование IoC - PullRequest
3 голосов
/ 28 января 2012

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), создайте экземпляр универсального конструктора с текущим экземпляром репозитория, а затем передайте ему интерфейс и функцию.

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

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

Ответы [ 3 ]

8 голосов
/ 28 января 2012

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

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

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

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

Edit

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

5 голосов
/ 28 января 2012

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

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

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

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

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

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

2 голосов
/ 28 января 2012

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...