Что почитать о проектирование веб приложения для MVC подели?
Пишу сейчас на Yii и стараюсь делать приложения такими, что бы самому стыдно не было и код был более универсален, что бы в будущем использовать его вновь.
Вот банальный пример. Есть небольшой веб сайт (10 страниц + раздел новости + формы обратной связи).
С моделями понятно - модель статической страницы и модель новостей, модель для валидации формы связи. Или можно универсальную модель, где указывать тип страницы (новость или статическая). С представлениями тоже понятно - в зависимости от дизайна страниц.
А вот с контроллерами как? Сделать контроллеры для каждой сущности? Допустим контроллер новостей с действиями read, list. А действия для создания новостей и редактирования (панель управления) добавить в него же или создать для всей панели управления другой контроллер?
Просто возникает куча вопросов, какие контроллеры создать, как назвать методы. Я их решаю, но постоянно чувствую недостаток знаний.
Предполагается отдельная панель с настройками и возможностью выполнять различные операции над каждой сущностью.
Позвольте уточнить. То есть, если я хочу реализовать кроме базового приложения (веб сайт), например еще одно (api интерфейс для мобильного приложения или форум или панель управления) то логичнее это организовать в виде модуля, что бы не засорять основное приложение дополнительными контроллерами и т.д.. Правильно я понял?
Вообще один экшен должен делать только одно. Более того, рекомендую функционал сразу делить на модули. Для админ панели да, нужно отдельный контроллер, так как там фильтры доступа, права пользователей различаются...
Документацию читал. Не очень разобрался, что именно делать с контролерами. Точнее, как оно устроено я понимаю. Но мне нужно выбрать, какие контроллеры создать. И все решения, что приходят в голову - кажутся не очень красивыми.
Судя по комментарию, вы не поняли сути Контроллеров. Для начала, нафига он нужен! Представим у вас сайт и пользователь заходит на одну из внутренних старниц, например mydomain.com/blog .
Данный запрос должен кто то разрулить и вывести пользователю какую то страницу. К данному url (маршруту, см. роутинг) мы прикручиваем контроллер, который и будет разруливать данный запрос (или целую группу запросов) посредсвом экшенов (actionIndex, actionДругоеЛюбоеНазвание).
Задача которую должен(!) выполнять контроллер - это взять данные откуда то (например база данных, см. Модели), возможно сохранить данные или обновить или вовсе удалить (а может и ни чего из этого) и как то отобразить их (то есть передать в представлеине, см. Представление).
Пример: вы хотите блок, у которого есть лента с последними добавленными поставми и каждый пост можно отдельно посмотреть. А если мы авторизованы, мы может удалить любой пост.
И так сразу же формируем маршруты:
/blog - показывает ленту
/blog/view/1 - показывает необходимый пост, где цифра это id поста в базе данныз (Модели)
/blog/delete/1 - удаляет запись с id 1
Прописали все это в маршрутах (естественно вместо цифр 1 нужно написать, что то типо :id, ведь у нас туда может прийти любой другой id поста).
Теперь надо каждый маршрут обработать. Делаем контроллер BlogController, который и будет отвечать за обработку всего, что связанно с блогом ("все", это то что в рамках данного ответа, это очень приметивный пример. Например если внутри каждого поста есть комментарий, которые добавляются постредством ajax, то лично я бы сделал на них отдельных контроллер, CommentController. Это вопрос архитектуры). И так, у нас 3 марштура, которые выполняют разные задачи. Для них делаем 3 экшена в контролле:
actionIndex() - это экшен выполняемый по умолчанию, то есть маршутр /blog и /blog/index единтичны.
actionView(id) - принимает id, берет из базы запись с этим id и выводит
actionDelete(id) - удаляет.
Если вы подразумеваете "дальнейшее использование" под переносимость кода в другие проекты, то Да. Нужно реализовывать все в виде модулей (с миграциями для полноты). Если Юпи проект, можете посмотреть его архитектуру yupe.ru (см. github)
если вас парит архитектура на данном этапе развития, это похвально. Читать про тонкие контроллеры, про паттерны, про inversion of control в частности... Почитайте про выделение функционала в сервисный слой, почитайте про модульное тестирование (очень помогает иногда найти оптимальный уровень абстракции, особенно в купе с tdd). Правда есть риск что прочитав все это вы решите выбросить yii так как он не очень то хорошо справляется с "best practice" архитектурных решений.
@Jakeroid Symfony2/Zend2. Не поймите не правильно, по феншую можно на чем угодно писать. Вопрос в количестве бойлерплейт кода который нужно добавить и на какие компоненты что поменять. Можно писать хорошо и красиво и на Laravel и на Yii2 и на том же CakePHP если очень сильно поднапрячься. Просто обычно, в большинстве случаев, разработчики не могут даже дефолтный функционал освоить и обычно стремятся к упрощению решений. Чем проще какой-то фреймворк позволяет делать неправильные вещи, тем чаще эти неправильные вещи будут совершаться.
Средний
