Есть ли менее подробное решение, чем использование шаблона фабрики провайдеров?

2

Когда вышла .NET 2.0, меня очень впечатлил шаблон Provider Factory, используемый для нескольких служб, которые были развернуты в то время... и начал использовать его повсюду.

Но потом я столкнулся с настоящими неприятностями:

  • В CE не было никакой системы конфигурации, поэтому ее нелегко было портировать в эту среду (и, следовательно, вызывать серьезные вилки в коде, которые могли бы хорошо работать на обеих платформах с помощью всего лишь нескольких модификаций)
  • Я никогда не нашел хорошего ответа на вопрос о том, как и статический менеджер обернул все методы Поставщиков: поставщик-провайдер мог реализовать интерфейс, но интерфейсы (AFAIK) не могут использоваться для статических методов. Таким образом, всегда существовала вероятность расхождения между обернутым поставщиком и статическим менеджером.
  • Количество котельного табличного кода, пробитого крышей, и моя производительность обратно упала через пол. Под этим я подразумеваю, что вместо просто вызова instance.Method();

Я вызывал это, но через статический Manager.DoWork(), который вызывал свой экземпляр DoWork(), который обычно заканчивался тем, что был общим кодом в классе ProviderBase, который проверял args, выполнял некоторую работу и, наконец, называемый абстрактным InternalDoWork(), который был реализован в классе CustomProvider...

Другими словами... очень извилистый способ вызова метода (от 3 до 4 методов, проверка аргументов повсюду, нечеткость того, где пытаться/улавливать/регистрироваться в менеджере или ProviderBase? -etc.

Итак, мой вопрос: есть ли еще один шаблон (ы), который я могу посмотреть, чтобы предоставить возможности конфигурации конфигурационного файла, позволяя динамическое изменение - ну, по крайней мере при перезагрузке - поставщика услуг?

PS: В последнее время я много слышал о IoC/DOI как о возможном более быстром решении... хотя и не использовал его в производстве. Это выглядит интересно... Но мое первое впечатление заключается в том, что у DOI есть своп услуг, настраиваемых в конфигурационном файле, но не настройка параметров из файла конфигурации?

Спасибо!

  • 0
    Слава за то, что вы указали, используя примеры из реальной жизни, почему [вставьте любимый шаблон дизайна здесь] не всегда серебряная пуля
Теги:
design-patterns

3 ответа

1

Если вы хотите изучить инъекцию зависимостей, я бы рекомендовал Ninject или StructureMap. Существует немало вопросов StackOverflow о контейнерах .NET IoC, хотя, поэтому просто выполните поиск, и вы найдете намного больше информации.

Что касается вашего фактического вопроса, эта тенденция, по-видимому, относится к модели на основе композиций, а не к Subtyping, который используется моделью поставщика. Это, по-видимому, более тесно связано с более новым материалом, выходящим из Редмонда, например ASP.NET MVC.

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

В целом, я думаю, что инъекция зависимостей лучше для кода приложения, так как состав вашего приложения часто делает его менее тесно связанным, чем определение строгой модели наследования, и обычно упрощает код unit test. Кроме того, многие проблемы, обычно цитируемые с составом, менее важны для кода приложения, чем для фреймворков (опять же, для управления версиями). Правда, вероятно, где-то посередине, как видно из MVC, где зависимости между компонентами используют простые интерфейсы (Composition), но базовые классы, реализующие общие функции, также доступны для наследования и переопределения только необходимых бит.

Вот почему контейнеры IoC, как правило, помогают здесь, потому что они обеспечивают слабосвязанные средства для системы, чтобы запросить компонент без необходимости знать что-либо о реализации. Например, DependencyResolver.GetInstanceOf<IUserRepository>().

0

Я думаю, вы захотите изучить библиотеки Injection Dependency, такие как @David Unity. Я предпочитаю Autofac. Но есть и другие http://en.wikipedia.org/wiki/Dependency_injection.

0

Блок приложений Unity из группы Microsoft Patterns and Practices довольно хорош. Хотя, вероятно, не единственный или лучший из них. Кроме того, MEF-структура очень хорошо говорит о себе на землях Microsoft, поскольку они используют/интегрируют ее в Visual Studio 2010.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню