Является ли StaticFactory<T> в codecampserver хорошо известным шаблоном?
Исходный код CodeCampServer содержит универсальный StaticFactory.
Я предполагаю, что это ключевой элемент механизма того, как структура хорошо работает с Dependency Injection.
Подклассы, использующие его DefaultUnconfiguredState для обеспечения статического доступа к самонастраиваемому состоянию по умолчанию, который механизм замены зависимостей может заменить рабочим.
Я не смог найти никакой документации для этого...
Есть ли хорошее объяснение в книге? (Я жду доставки от Амазонки...)
... или кто-нибудь еще может дать хороший комментарий о том, что это такое, и было бы разумно принять этот шаблон (если он один...)?
Обновить
Поскольку Джеффри Палермо ответил на этот вопрос, я вижу, что в (незавершенной) рукописи для MVC2 в действии этот шаблон / стиль обсуждается и иллюстрируется с использованием Фабрики, которая используется для определения местоположения репозитория, чтобы держать доменный уровень в неведении. постоянных забот. (см. главу 23).
По умолчанию использование этой фабрики вызывает исключение:
"знание того, как создать хранилище, не зависит от фабрики. Эта фабрика просто представляет возможность вернуть хранилище"
В этом примере мог бы использоваться один из нескольких механизмов для инициализации конкретной реализации интерфейса репозитория. В примере из книги они решают не использовать контейнер IOC для простоты и предоставляют это явно в некоторой логике запуска.
"Важно то, что ни базовый проект, ни проект пользовательского интерфейса не должны ссылаться на проект инфраструктуры или библиотеки, которые имеют чисто инфраструктурный характер. Мы полностью отодвинули NHibernate в сторону, так что остальному приложению все равно, как доступ к данным происходит
И последнее замечание, касающееся примера кода в этой новой главе, заключается в том, что Factory больше не является статичным (по крайней мере, в том, что касается внешнего интерфейса).
Обновление 2
Г-н Палермо написал еще немного об этом особом стиле Abstract Factory (см. Реализацию OrderShipperFactory).
Я мог бы также просто подумать о "ручном введении зависимостей" (дядя Боб).
Обновление 3 - март 2016
Здесь есть еще один пример, хотя Джеффри явно говорит о том, что это демо-код, и комментарий указывает, что он будет настроен так, как Марк Симан назвал бы корнем композиции (т.е. при запуске приложения).
Я обнаружил это в статье Джеффри " Луковая архитектура: часть 4 - после четырех лет"
2 ответа
Хороший вопрос. Мне это тоже не нравится. Он действительно должен называться "StartupFactoryConfiguration", но он находится в списке рефакторинга.
Мы поэкспериментировали с этой идеей в качестве способа настройки DI для мест, которые не были введены конструктором через контейнер.
Это уйдет. Я не знаю, что такое анти-паттерн (как называется?), Но StaticFactory умрет.
Теперь он был переименован по состоянию на это утро. Теперь это AbstractFactoryBase. Это реализация шаблона абстрактной фабрики: http://en.wikipedia.org/wiki/Abstract_factory_pattern
Реализация фабрики заключается в том, чтобы в конечном итоге вызвать ограничитель IoC, но он позволяет получить доступ из кода в месте без ссылки на сборку контейнера IoC.
С уважением, Джеффри Палермо
Все статичное - враг DI.
Этот StaticFactory выглядит как реализация шаблона ServiceLocator (anti-).
Я считаю ServiceLocator антипаттерном, так как он абсолютно непрозрачен для пользователя API, какие зависимости должны быть на месте; таким образом, можно легко вызывать методы для объектов в контексте, в котором выдает ServiceLocator, и API не дает вам абсолютно никакой подсказки, что это так.
Правильный DI, такой как обильное использование Constructor Injection, является гораздо лучшей альтернативой.