как включить субдомены в инфраструктуру MVC

Question

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

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

Мой фреймворк работает, разделяя URL запроса на / и определяя, что является контроллер, параметры действий .. и т.д ..

и это прекрасно работает, но что делать с поддоменами?

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

http://kodi.shop.local/

(я добавил SeverAlias ​​* .shop.local)

вот так выглядит мой объект запроса:

DPLS_Request Object
(
    [_request] => Array
        (
            [0] => 
            [1] => 
            [action] => defaultAction
            [controller] => home
        )

    [_params] => Array
        (
        )

    [_rurl:private] => kodi.shop.local
    [_segment] => kodi
    [get_params] => Array
        (
        )

)

Итак, _segment - это поддомен, и позже я могу использовать его в коде для проверки его соответствия имени пользователя и другим вещам, но у меня возникли концептуальные проблемы еще до этого. Моя проблема в том, что моя структура ожидает, что какой-то контроллер и действия будут переданы, и потому что все, что он получает в конце URL-адреса, это / он предполагает, что это должно показать страницу индекса: (

что делать дальше ... как включить субдомены в историю контроллеров / действий mvc?

Одно быстрое и грязное решение - изменить часть моего класса запросов:

if($this->_request['controller']==''){ 
    $this->_request['controller'] = DEFAULT_CONTROLLER; 
}
if($this->_request['action']==''){
    $this->_request['action'] = DEFAULT_ACTION; 
}

и обернуть это в еще один , если , чтобы проверить, присутствует ли _segment, и если он назначен контроллеру DEFAULT _SHOP _CONTROLLER, который я определю в файле конфигурации, как, скажем, «store»

поэтому запрос выше будет аналогичен вводу http://shop.local/store/ (он запустит контроллер 'store' и действие по умолчанию)

что бы вы сделали в этом случае? Есть ли «лучшие практики» при работе с поддоменами, контроллерами и действиями?

Answer 1

Мне кажется, что описанный вами подход является логическим следующим шагом для реализации добавляемых вами функций. Новые функции принесут некоторую дополнительную сложность, но ваш объект / маршрутизатор Request должен хорошо выполнять инкапсуляцию логики «Какой контроллер я вызываю, когда предоставляется сегмент? Когда предоставляется сегмент И контроллер?» и т.д. Я говорю, пойти на это.

Answer 2

Лично я бы не стал добавлять в вашу среду всевозможные «особые» условия, связанные с поддоменами, потому что то, что поддомены означает в одной ситуации, не обязательно означает то же самое в другой ситуации. (Кроме того, чем больше фреймворк предполагает, тем более хрупким он становится)

Например, некоторые люди используют субдомены для определения локали (en.site.com для английской версии, fr.site.com для французского ...), но при такой настройке будут использоваться «одинаковые» контроллеры no независимо от того, на какой язык переводится сайт.

Просто выполните простое правило перезаписи, например: переписать * .store.site.com в * .site.com / store /

Answer 3

То, о чем вы говорите, звучит как мультитенантность. Майк Хэдлоу (Mike Hadlow) хорошо описывает свой подход к проблеме в приложении ASP.NET MVC, которое он создает, и вы можете прочитать его здесь: http://mikehadlow.blogspot.com/2008/11/multi-tenancy-part-2-components-and.html