Использование шаблона провайдера - несколько абстрактных классов

Question

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

//Same Customer provider dll      
//Methods defined for handling web service integration
public abstract class XMLBaseProvider : ProviderBase


//Methods defined for handling web page integration logic
public abstract class XMLWebPageBaseProvider : XMLBaseProvider

Теперь в app.config я определяю другой раздел поставщика, который указывает на XMLWebPageBaseProvider вместе с новым именем поставщика.Это работает, но интересно, я злоупотребляю шаблоном провайдера, кодирующим его таким образом?Есть ли какие-либо проблемы или ошибки, которые я должен волновать, делая это.Кто-нибудь здесь реализовал этот шаблон провайдера, как я описал выше?

Также обратите внимание, что мы, вероятно, получим больше клиентов, которые будут интегрироваться с нами с помощью интеграции веб-страниц.Я просто не хотел бы, чтобы в решение добавлялось все больше и больше провайдеров (dll).

Спасибо, DND

Answer 1

Я думаю, что ваши идеи хороши.Для того, что вы описали, ваш дизайн будет работать нормально.Однако, как отметил один из комментаторов, требования могут расшириться до JSON.По моему опыту, потребность в различных форматах всегда растет со временем.Когда это происходит, наследование становится довольно хрупким.Иерархия классов вырастет до все большего числа абстрактных классов.В конце концов, это будет трудно управлять.

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

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

Эта стратегия обычно называется программированием на основе данных.Посмотрите на этот вопрос .