Шаблон проектирования для вызова различных бизнес-правил для представленных элементов пользовательского интерфейса

Question

Я работаю над проектом, который разрабатывает веб-приложение для 3 клиентов.Все клиенты довольны базовым продуктом, который мы производим.У 2 из них есть несколько отличающиеся требования - о видимости определенных элементов управления, различной привязке данных к выпадающим спискам и т. Д.

Мой вопрос - зная, что каждый из 3 клиентов будет продолжать приходить со своими собственными конкретными требованиямиКаков наилучший способ реализации этих требований в пользовательском интерфейсе?

Мне не нравится идея иметь серию операторов IF в каждой имеющейся у меня веб-форме, которая управляет выпадающими списками и контролемвидимость индивидуально.Это просто засоряет мои хорошо организованные файлы с пользовательскими требованиями.

Может ли кто-нибудь указать мне схему (ы), которая может соответствовать требованиям?

Взгляните на этот упрощенный гипотетический пример, чтобы увидеть, чтоЯ имею в виду:

• Веб-форма заполнена раскрывающимся списком, в котором есть 3 пункта меню (например, домашний номер, служебный номер, международный номер);раскрывающийся список используется для записи типа номера телефона для контакта

• 2 моих клиентов с радостью свяжут с контактом столько типов телефонов (даже если возможны дубликаты)

• 1 клиент хотел бы, чтобы мы указывали в раскрывающемся списке «Домашний номер» и «Международный номер», только если текущий контакт уже связал «служебный номер» со своим профилем

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

Answer 1

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

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

Другой вариант - требовать, чтобы каждая страница проходила через различные дополнительные шаги, возможно, путем создания собственных событий "OnXXX" (OnOurCompanyPreInit, OnOurCompanyInit и т. Д.), В которых вы размещаете дополнительную логику для каждого клиента.

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

Answer 2

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

Проект ASP.Net разработан на модульной общей основе, которую получают все клиенты.

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

Таким образом, в базовом вызовемоя страница, у меня есть что-то вроде этого:

protected void Page_Load(object sender, EventArgs e)
{
    PreRender += ConfigurationInterceptors;
}

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

protected void ConfigurationInterceptors(object sender, EventArgs e)
{
    Interceptor interceptor = new Interceptor(this.Page);
}

Класс Interceptor представляет собой автономный уровень, который запускает серию вызовов FindControl и изменяется по мере необходимости.

Таким образом, этот шаблон позволил нам поместить индивидуальные настройки клиента в отдельный бункер и не усложнять базуобщая кодовая база.

Answer 3

Я бы сказал, что вам нужно использовать Шаблон состояния , но может быть и много других способов.