Каково соглашение по URL-структуре в шаблоне MVC / HMVC / PAC? - PullRequest
Новая
       35

Каково соглашение по URL-структуре в шаблоне MVC / HMVC / PAC?

5 голосов
/ 12 февраля 2011

В MVC это похоже на http://www.yourdomain.com/sampleController/sampleAction/, и если вы звоните просто /sampleController/, тогда /sampleController/indexAction/, а если вы просто звоните /, то /indexController/indexAction/ срабатывает.

Конечно, есть исключения, но это более или менее соглашение.

У Зенда есть что-то нелепое. Они называют это Модули.

В основном это просто папки, каждая из которых содержит логику MVC. Так что вы можете позвонить /Module1/Controller/Action/. Если вы просто позвоните /Module1/, то /Module1/indexController/indexAction/ сработает. Это удобно, если у вас огромный проект, потому что вы можете структурировать еще больше, но это раздражает, если у вас есть небольшой проект.

Так что мне очень нравится идея HMVC / PAC и я хочу принять ее в свои рамки.

Правильно ли я понял, что он в основном такой же, как Zend, но с неограниченным количеством вложенных модулей?

Так, например, у меня есть /sub-project/sub-sub-project/controller/action/?

А что такое соглашение, если я позвоню /A/B/C/D/.

Означает ли это действие D в контроллере C в модуле A / B? Или IndexAction в контроллере D в модуле A / B / C?

Давайте приведем пример: 

Content
    ToplistController 
        AdministrateAction
        IndexAction
ContentController
     ToplistAction
Users
    Chat
        RoomController
            IndexAction

Я сейчас звоню по URL /content/toplist/.

Для URL /users/chat/room/?room=1 пример делает это очевидным, поскольку существует только одна возможность. Но так ли это? Существует ли соглашение об уникальном обращении к нужному действию в правильном контроллере?

Моей первой идеей было «угадать как можно меньше».

Поэтому я сначала проверяю, соответствует ли URL-адрес действию.

И если есть контроллер / модуль, называемый так же с действием index, он просто не может сработать, если присутствует совпадение на «более высоком уровне».

Если это не так, я вижу, соответствует ли URL-адрес непосредственно контроллеру и добавляет IndexAction.

Если это не так, я ищу модуль и думаю, IndexController и IndexAction, а если это не так, я ищу модуль с именем index.

Но я бы хотел избежать этого, если / else вещи и доступ к файловой системе. Вот я и подумал, как проходит конвенция. Или есть хоть один? Я не смог найти ни одного примера!

Или что-то вроде вызова IndexAction, если ничего не указано, просто не сделано, но каждый "короткий URL" должен быть указан в отдельной логике маршрутизации?

Или я совершенно неправильно понял концепцию HMVC / PAC?

К вашему сведению: я включил тег php, потому что я делаю свою инфраструктуру в php и хочу узнать о соглашениях в php. Я часто видел различия в других языках программирования.

Ответы [ 2 ]

2 голосов
/ 11 марта 2012

Одно простое (и, как мне кажется, общепринятое) соглашение - это наличие / отсутствие завершающего слеша, где A / B / C / D / подразумевает IndexAction в контроллере D, а A / B / C / D - действие D в контроллере С.

1 голос
/ 12 февраля 2011

Официальных рамочных соглашений не существует.

URI идентифицируют ресурсы . Каким образом какая-то структура отображает эти URI во внутренние функции приложения, зависит от этой структуры. Например, если вы хотите выполнить REST, у вас вообще не будет никаких действий, потому что действия подразумеваются используемыми HTTP-глаголами , например, 

DELETE http://example.com/resourceName/1234

тогда как в «маршрутизируемой» структуре может быть что-то вроде 

POST http://example.com/resourceName/delete (with POST Body 1234)

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

...