Является ли StaticFactory<T> в codecampserver хорошо известным шаблоном?

Question

Исходный код CodeCampServer содержит общий Статический завод.

Я предполагаю, что это ключевая часть механизма того, как фреймворк хорошо справляется с внедрением зависимостей.

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

Я не смог найти никакой документации по этому поводу...

Есть ли хорошее объяснение в книга?(Я жду доставки от Amazon ...)

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

Обновить

Поскольку Джеффри Палермо ответил на этот вопрос, я вижу, что в (незавершенной) рукописи для MVC2 in Action этот шаблон / стиль обсуждается и иллюстрируется с использованием фабрики, которая используется для определения местоположения репозитория, чтобы уровень домена не знал о проблемах с сохранением.(см . глава 23).

По умолчанию использование этой фабрики вызывает исключение:

"знания о том, как создать репозиторий, не хранятся на фабрике.Эта фабрика просто представляет возможность возврата репозитория"

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

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

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

Обновление 2

Мистер Палермо написал в блоге еще кое-что о этот особый стиль Абстрактной фабрики (смотрите реализацию OrderShipperFactory).

Я тоже мог бы просто подумайте о "Ручном внедрении зависимостей" (Дядя Боб).

Обновление 3 - март 2016

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

Я обнаружил это в статье Джеффри ".Луковая Архитектура:Часть 4 - Спустя четыре года"

Answer 1

Хороший вопрос.Мне это тоже не нравится.На самом деле он должен называться "StartupFactoryConfiguration", но он находится в списке рефакторинга.

Мы поиграли с этой идеей как со способом настройки DI для мест, которые не были внедрены конструктором через контейнер.

Это пройдет само собой.Я не знаю, что такое анти-паттерн (какое название?), но StaticFactory умрет.

---

Теперь, по состоянию на сегодняшнее утро, он был переименован.Теперь это AbstractFactoryBase.Это реализация абстрактного фабричного шаблона: http://en.wikipedia.org/wiki/Abstract_factory_pattern

Реализация factory заключается в конечном вызове IoC contrainer, но это позволяет получить доступ из места в коде без ссылки на сборку контейнера IoC.

С уважением, Джеффри Палермо

Answer 2

Все статичное - враг DI.

Этот StaticFactory выглядит как реализация Сервисный Локатор (анти-)паттерн.

Я считаю, что Service Locator является антишаблоном, поскольку он полностью непрозрачен для пользователя API, какие зависимости должны быть установлены;таким образом, можно было бы легко вызывать методы для объектов в контексте, в котором был бы выдан Service Locator, и API не дает вам абсолютно никакого представления о том, что это так.

Правильный ДИ, такой как обильное использование Инъекция конструктора это гораздо лучшая альтернатива.