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

Question

Исходный код CodeCampServer содержит общий StaticFactory .

Я предполагаю, что это ключевой элемент механизма того, как структура хорошо работает с Dependency Injection.

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

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

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

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

Обновление

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

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

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

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

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

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

Обновление 2

Мистер Палермо написал еще немного о этом особом стиле Abstract Factory (см. Реализацию OrderShipperFactory).

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

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

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

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

Answer 1

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

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

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

---

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

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

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

Answer 2

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

Этот StaticFactory выглядит как реализация Service Locator (anti-) pattern.

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

Правильный DI, такой как обильное использование Конструкторский впрыск - намного лучшая альтернатива.