Разработка сайта ASP.NET MVC 3 для поддержки индивидуальной настройки просмотра без разветвления - PullRequest
4 голосов
/ 14 января 2012

Я работаю над большим сайтом ASP.NET MVC, коммерческим сервисом, который продается клиентам. Мы продаем в основном мелким и крупным учреждениям, поэтому не в термоусадочной упаковке. Эти крупные клиенты будут просить нас сделать настройки, в основном более широкие, чем, в том числе, настройку макета в соответствии с их сайтом.

В настоящее время мы думаем, что даже после того, как MVC доведет до своего естественного завершения очень простые контроллеры, которые вызывают только другой код (как рекомендовано), представления будут сложной проблемой, потому что они плохо поддаются такому виду. в любом случае не с Razor, как мы использовали. Их трудно разделить на подклассы и сказать «для этого клиента сделайте что-то немного больше»; в частности, трудно подать немного другой HTML для одной и той же конструкции.

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

Каково современное состояние дел в этом? Какие военные истории? (Это может быть субъективно, но в основном это объективно в том смысле, что если есть шаблон или подход, который полностью сокращает это до сути, конечно, это правильный ответ. И я думаю, что это интересный вопрос.)

Я рад предоставить более подробную информацию.

Ответы [ 2 ]

1 голос
/ 14 января 2012

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

Стратегии, которые я использовал:

  1. Сосредоточьтесь на функциях и конфигурациях, а не на клиентах. У нас есть набор основных функций для каждого учреждения. Только некоторые из этих функций являются настраиваемыми. Для каждого учреждения мы поддерживаем преобразование Web.Config, которое содержит их выбор для настраиваемых функций. Параметр публикации используется для управления тем, какое преобразование используется при публикации приложения этого учреждения. Представление / контроллер использует данные конфигурации для реализации варианта функции, указанной для этого учреждения. Он не знает, какое это учреждение, просто конфигурация говорит «делай A, а не B, при рендеринге виджета C».

  2. Разделите темы на общие и специфичные для сайта компоненты. Большинство CSS / изображений являются общими для всех организаций, однако мы загружаем последний CSS-код для конкретных сайтов, позволяя переопределения для конкретного сайта. В основном это цвета, фоны и изображения для конкретных учреждений (баннеры и т. Д.). Мы помещаем специфичные для сайта темы в отдельные папки внутри content/themes. Элемент конфигурации используется для установки папки темы, и основные представления извлекают этот элемент конфигурации при создании URL-адреса для CSS и любых специфичных для сайта изображений (большинство, если не все, они обрабатываются в самом файле CSS сайта).

  3. Поддерживайте строго типизированный класс конфигурации, который включает стандартную конфигурацию. Внедряйте этот класс в контроллеры, почтовые программы и т. Д. Везде, где требуется конфигурация. Поскольку мы полагаемся на конфигурацию во всем приложении, мы чувствовали, что продвижение этого объекта до первоклассного объекта в нашей модели было важно для удобочитаемости и удобства обслуживания. Для недвоичных опций мы обычно создаем enums, который сопоставляется с настройкой, чтобы избежать сравнения строк. Для более сложных приложений или нескольких организаций я бы, вероятно, даже разработал отдельный обработчик раздела конфигурации и разделил бы конфигурацию на отдельный раздел или файл конфигурации. На данный момент наш использует appsettings, поскольку количество настроек невелико и они относительно просты.

Надеюсь, это поможет.

1 голос
/ 14 января 2012

Звучит так, будто вы хотите взглянуть на многопользовательские виды, недавно была хорошая статья Роба Эштона на эту тему .

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...