Архитектура / Шаблон для настраиваемого приложения (веб в моем случае) - PullRequest
Новая
       28

Архитектура / Шаблон для настраиваемого приложения (веб в моем случае)

0 голосов
/ 06 августа 2009

Я уже задавал этот вопрос на форуме asp.net, не смог найти удовлетворительного ответа. Вы можете посетить его, чтобы получить более подробную информацию. http://forums.asp.net/t/1420283.aspx

У нас есть продукт, который можно настроить для каждого клиента.

Варианты конфигурации: пользовательский интерфейс и бизнес-логика.

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

В бизнес-логике множество ветвей «Переключение / выбор», реализующих логику в соответствии с настройками каждого клиента. (Мне интересно, если я могу выбрать подключить внешнюю сборку / DLL (проект построен) во время выполнения в зависимости от клиента, что означает, что общая база кода будет вызывать внешний код для каждого клиента для обработки вещей в соответствии с их потребностями .... ..... или, может быть, просто разделить логику разных клиентов в их собственных классах)

Прямо сейчас пользовательский интерфейс полностью создается во время выполнения ..... что, по моему мнению (IMO), не является необходимым, поскольку после настройки пользовательский интерфейс остается статическим для клиента (за исключением улучшений, которые очень малы и находятся далеко друг от друга).

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

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

Ответы [ 2 ]

2 голосов
/ 06 августа 2009

Что касается вашей бизнес-логики, кажется, что вы пытаетесь сделать довольно сложные вещи, основываясь на пользовательских настройках. Возможно, вы захотите подумать о механизме коммерческих правил, чтобы помочь Один из тех, что я видел в прошлом:

InRule

1 голос
/ 06 августа 2009

Посмотрите на структуру Django для руководства по таким вещам.

  1. Каждый клиент имеет отдельное «приложение», построенное из общего набора библиотек и компонентов. Уникальное приложение клиента является расширением основного приложения.

  2. Функции просмотра выполняют реальную работу.

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

    Нет веток «Переключить / Выбрать регистр», поскольку логика каждого клиента - это его уникальная логика. Чтобы минимизировать усилия, необходимые для написания клиентской версии, мы включили столько общей логики из библиотеки универсальных компонентов. Мы всегда перемещаем вещи, которые используются более чем одним клиентом, в общие библиотеки и переписываем код клиента, чтобы упростить его.

  3. Шаблоны генерируют HTML-страницы.

    Шаблоны находятся в пути поиска шаблонов.

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

Что не имеет массивного приложения с множеством операторов if для его настройки. У нас есть несколько небольших приложений, которые расширяют общее базовое приложение.

...