Код вашего собственного контейнера МОК

Question

Кто-нибудь там писал свой собственный контейнер IOC на C #? Или подавляющее большинство людей используют различные фреймворки, такие как Spring. Какие плюсы и минусы у каждого?

Answer 1

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

Answer 2

Мне понравилась эта 33-строчная контейнерная реализация от Кена Эгози, вдохновленная 15 лайнером Айенде

Answer 3

Кто-то написал один на C #: http://ninject.org/.

Это открытый исходный код, так что вы можете получить код и посмотреть, как этот парень сделал это.

Answer 4

Если вы ищете легкий и высокопроизводительный контейнер IoC, то вам стоит проверить Munq

Answer 5

Я написал контейнер IoC / DI на языке c #, который реализует Common Service Locator. Я написал это в основном для учебных целей, но когда я закончил, я решил сделать его открытым исходным кодом. Если кто-то из вас захочет попробовать IInject , он может загрузить здесь .

Answer 6

Если нет очень веской причины, я бы не стал изобретать колесо и сам реализовывать контейнер IoC, особенно потому, что есть много хороших вариантов, таких как Unity , Ninject или Spring. нетто .

Если вам нужно / хотите удалить зависимость от любого из этих контейнеров IoC, вы можете попробовать интерфейс Common Service Locator .

Answer 7

Autofac отлично.

Я сам написал менее 15 строк. Всего два метода расширения для словаря.

Answer 8

Джеймс Ковач представляет эпизод dnrTV на эту тему здесь . Вот также написал статью . Однако в статье он упоминает, что вы, вероятно, захотите использовать один из готовых. Так как их очень много. Ninject, StructureMap, Autofac используют свободный интерфейс. Spring, Castle Windsor и Unity более ориентированы на XML-конфигурацию. Замок Виндзор также может использовать Бу в качестве интерфейса. У многих есть привязки к другим фреймворкам, таким как Unity для EntLib или Castle Windsor для Monorail и остальная часть проекта Castle.

Так что, если вам действительно не нужно или не нужно что-то, что не предоставляется доступными структурами IOC, то почему бы не использовать одну из них.

Answer 9

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

Реальный вопрос в том, почему и как еще одна новая контейнерная структура МОК может принести пользу?

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

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

Вы можете проверить это здесь: Puresharp API .net 4.5.2 +

Answer 10

Я создал свой собственный контейнер IoC, который облегчает отладку создания объекта (даже если у вас нет доступа к коду контейнера). Когда объект создан, нажимая Шаг в (F11), вы видите код для создания объекта. Полный код можно увидеть здесь .