По какой-то причине в MVC нет эквивалента 1: 1, давайте просто повторим, как думать об этом с точки зрения MVC:
Модель: «Страницы этого сайта всегда запрашиваются в определенном контексте, назовем его арендатором (или пользователем, темой или чем-то еще, что представляют ваши поддомены). Модель домена имеет свойство, представляющее арендатора текущий запрос».
Вид: "Визуализация заголовка страницы в зависимости от арендатора, установленного в модели".
Контроллер: «Установите арендатора в модели в зависимости от заголовка хоста».
Имейте в виду, что мы хотим избежать смешивания контроллера, представления и бизнес-логики. Наличие логики контроллера более чем в одном месте или в месте, которое не называется «контроллером», не является проблемой, пока оно остается разделенным.
А теперь хорошая вещь: Вы можете сделать этот «стиль MVC» даже с веб-формами, и решение по-прежнему работает с ASP.NET MVC!
У вас все еще есть жизненный цикл запроса (а не жизненный цикл страницы), поэтому вы можете реализовать собственный HttpModule, который содержит эту часть логики контроллера для всех запросов. Он обрабатывает событие BeginRequest, проверяет заголовок хоста и сохраняет арендатора во что-то вроде HttpContext.Current.Items["tenant"]. (Конечно, у вас может быть статическая типизированная оболочка для этой словарной статьи.)
Затем все ваши объекты модели (или базовый класс модели, или что-то еще, что подходит для вашего решения) могут получить доступ к HttpContext, чтобы предоставить доступ к этой информации следующим образом:
public string Tenant
{
get { return HttpContext.Current.Items["tenant"]; }
}
Преимущества:
- Вы разделили причину (заголовок хоста) и следствие (заголовок страницы рендеринга), улучшив удобство сопровождения и тестируемость.
- Таким образом, вы можете легко добавить дополнительное поведение в свою доменную модель на основе этого состояния, например загрузку контента из базы данных в зависимости от текущего арендатора.
- Вы можете легко сделать так, чтобы другие части представления зависели от арендатора, например, подключаемый файл CSS, изображение логотипа и т. д.
- Позже вы можете изменить логику контроллера, чтобы установить арендатора в модели не только на основе поддомена, но, возможно, на основе файла cookie, реферера, условия поиска, языка пользовательского агента или чего-то еще, о чем вы можете подумать, без изменения какой-либо из них. Ваш код в зависимости от модели.
Обновите ваше редактирование: мне не нравится идея сохранения состояния в сеансе, особенно если ваш файл cookie сеанса может применяться не только к каждому поддомену, но и ко всем доменам. В этом случае вы можете показывать противоречивый контент, если пользователи ранее посещали другой субдомен. Вероятно, информация в базе данных, которая сопоставляет заголовки хостов с арендаторами, не будет меняться очень часто, поэтому вы можете кэшировать ее и не искать базу данных для каждого запроса.
person
realMarkusSchmidt
schedule
07.03.2009