Я просто столкнулся с одним из ограничений архитектуры MVC, которую я сейчас использую для своих приложений. В настоящее время мои URL-адреса выглядят следующим образом:
www.example.com/controller/action Каждый запрос поступает на передний контроллер, который загружает запрошенный класс контроллера из URL-адреса и выполняет его действие (метод). Это отлично работает, пока вам не понадобится использовать вложенные контроллеры.
Пример: существует «пользовательский» контроллер, который содержит такие методы, как createUser (), editUser (), deleteUser () и т. Д. Все вполне возможно с текущей структурой URL … Но что, если нам также нужно управлять типами пользователей? Нам понадобится отдельный тип «usertypes» контроллера, который также содержит такие методы, как createUserType (), editUserType () … Однако, поскольку пользовательские типы являются частью пользователей, контроллер «usertypes» должен быть вложен в пользовательский контроллер, так как это :
www.example.com/users/usertypes/addusertype
Однако с текущей структурой URL это невозможно … Как я могу использовать вложенные (или многоуровневые, если вы) контроллеры?
ОБНОВЛЕНИЕ: вот основное представление приложения, над которым я работаю: это базовое бизнес-приложение для административного отдела, где они могут добавлять, просматривать, редактировать и удалять данные из 3 категорий (Акции, Почтовые рассылки и Держатели карт). Каждая категория представляет собой таблицу в базе данных и имеет свои собственные поля. Учетные записи должны быть созданы администратором, пользователи не могут самостоятельно создать учетную запись, и они не могут проконсультироваться с их профилем пользователя.
Для каждой из этих категорий я создал контроллер, который содержит такие действия, как add (), edit (), getAll (), getSingle (), delete () … Каждое из этих действий вызывает соответствующие методы из модели и отображает соответствующие View (s).
Это было возможно с текущей структурой URL, которая имела URL-адрес:
example.com/promotions/add example.com/promotions/getsingle?id=123
Недавно они попросили меня также управлять типами рекламных акций, почтовых рассылок и держателей карт. Сейчас у них уже есть школьная скидка, 20% скидка и т. Д. Но они хотят добавить больше, как пожелают.
Это означает, что мне нужен контроллер PromotionTypes, который также содержит такие действия, как add (), getAll (), getSingle (), delete () … Было бы неплохо, если бы контроллер PromotionTypes мог быть вложен в исходный контроллер рекламных акций, что позволяет URL-адрес:
example.com/promotions/promotiontypes/add
вместо
example.com/promotiontypes/add
С моим текущим фронтальным загрузчиком это невозможно, так как первая часть URL-адреса автоматически обрабатывается как контроллер, а вторая часть – как действие для ее выполнения.
Вы не упоминаете, используете ли вы фреймворк, но обычным способом было бы, чтобы «маршрутизатор» применял специальную обработку к исключениям, например, маршрутизаторы Zend Framework
Похоже, вы связали контроллеры не с представлением, а с каждым объектом домена .
Кроме того, что со странной маршрутизацией? Почему нет :
POST "www.example.com/profile/42/type"
Потому что вы добавляете типы в профиль конкретного пользователя. Это переводит на выполнение метода postType() на контроллере Profile .
Если вы строите свой собственный механизм маршрутизации, возможно, этот ответ может быть полезным.
Суть в том, что вам не нужны такие странные контроллеры-контроллеры. Вам нужно посмотреть, какие у вас есть взгляды, а затем создать контроллер для каждого из них, вместо того, чтобы смотреть на слой модели.