Я должен инкапсулировать свой контейнер МОК?

Не шаблон, но Joel записал несколько статей при записи функциональной спецификации. Он также имеет образец здесь .

7
задан Ryan Emerle 19 November 2009 в 14:24
поделиться

3 ответа

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

Выберите контейнер IOC, который не является инвазивным. То есть такая, в которой объекты, соединяемые друг с другом, не имеют никаких зависимостей от контейнера IOC. В этом случае инкапсулировать нечего.

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

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

РЕДАКТИРОВАТЬ:

Я не Я не вижу способа гарантировать безопасность типов, за исключением:

  1. Проектирования относительно сложной реализации шаблона Builder вместе с реализациями посетителя, которые будут записывать файлы конфигурации IOC, или что-то подобное.
  2. Реализация типобезопасной конфигурации IOC. DSL. (Мой выбор, если у меня было несколько приложений, которым требовались заменяемые контейнеры IOC.)
7
ответ дан 7 December 2019 в 01:22
поделиться

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

Это также означает, что вы можете легко отключить контейнер IoC, если найдете что-то лучше. Недавно я сделал это, заменив контейнер Spring.net IoC на карту структуры.

Проект ASP.NET MVC Contrib на codeplex - довольно хорошее место для начала. Это то, на чем я основал свою реализацию.

1
ответ дан 7 December 2019 в 01:22
поделиться

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

Если вы считаете, что вам нужна такая гибкость, вы можете посмотреть проект Common Service Locator в CodePlex. Он делает именно то, что вы ищете: обеспечивает общий фасад для различных контейнеров IoC.

HTH!

1
ответ дан 7 December 2019 в 01:22
поделиться
Другие вопросы по тегам:

Похожие вопросы: