нужна альтернатива шаблону провайдера

Question

Я поддерживаю веб-приложение, которое использует шаблон провайдера, как описано ниже, для целей конфигурации.

http://msdn.microsoft.com/en-us/library/ms972319.aspx
http://msdn.microsoft.com/en-us/library/ms972370.aspx

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

Мы понимаем, что мы могли бы создать несколько провайдеров, используя вышеуказанный метод MSDN, но несколько провайдеров просто создали бы больше записей в web.config. Было бы неплохо свести к минимуму записи в web.config, так как это начинает расти.

Кто-нибудь нашел другой способ реализации модели провайдера?

Answer 1

Вы можете посмотреть на использование контейнера инверсии управления (IoC) (Google "Castle Windsor", или StructureMap, или AutoFac, или NInject, или Microsoft Unity). Используя IoC, вы можете настроить «провайдеров» в файле конфигурации или в начале вашего приложения.

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

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

Answer 2

Я полагаю, что вы можете сделать это с помощью любого МОК, который допускает настройку (а это большинство из них).

Способ, которым я собираюсь это сделать, - настроить AutoFac в коде на использование «известных» реализаций, но разрешить необязательное «переопределение конфигурации». Поэтому, если мы когда-нибудь «продадим» приложение, и кому-то понадобится другая реализация, они могут просто настроить его.

Узнайте больше на моем блоге - надеюсь, блог тоже получит хорошие комментарии: http://healthedev.blogspot.com/2011/12/making-custom-built-applications.html

Answer 3

Загляните сюда: http://geekswithblogs.net/joycsharp/archive/2009/04/10/aggregator-provider-pattern-an-extension-of-provider-pattern.aspx