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

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

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

Моя структура работает, разделяя 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; 
}

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

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

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


person kodisha    schedule 02.02.2009    source источник


Ответы (3)


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

person GloryFish    schedule 05.02.2009

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

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

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

person Mario    schedule 06.02.2009

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

person Giraffe    schedule 02.02.2009
comment
Хм, только что заметил, что вы создаете свою собственную структуру, и в этом случае вам, вероятно, потребуется предоставить функции, на которые опирается этот подход. Извините, я думал, что вы используете один из загружаемых фреймворков, который, вероятно, имел точки расширения, аналогичные тем, которые использует MH. - person Giraffe; 02.02.2009