Что делает фреймворк "истинным" фреймворком MVC?

Вы можете найти эту вики-страницу полезной.

Истинная структура MVC не имеет слоя M(odel). У CakePHP и друзей есть несколько умных классов для доступа к базе данных, которую они называют Моделью, оставляя основную часть обработки данных контроллеру.

Это неправильно. Модель должна выполнять всю обработку данных (и она может использовать для этого вспомогательные классы баз данных), а контроллер должен быть шлюзом между пользователем/веб-страницей и моделью. В большинстве случаев модель представляет собой простой PHP-объект, не подчиняющийся никаким правилам, поэтому фреймворк не может указывать эти правила.

Вот несколько вопросов, которые могут помочь вам понять, хороша ли ваша структура и верна ли она.

"Могу ли я запускать модульные тесты для своих классов MVC без фреймворка?"

И это применимо, даже если вы не пишете модульный тест.

Вы должны иметь возможность писать код, связанный с MVC, независимо от платформы. Когда ваше приложение получает некоторые входные данные из фреймворка, это должно быть в виде объектов с известными интерфейсами, без конкретных классов.

Дело в том, что истинная структура MVC не оказала бы (или очень ограниченного) влияния на саму архитектуру. В лучшем случае это просто обеспечит понятный и простой способ вызова приложения для доступа к вашим триадам MVC. И, возможно, предоставить удобства для Вас.. а не ограничения и ограничения.

"Работает ли он на волшебной и волшебной пыли?"

Вы должны иметь возможность расширять любой класс, который был предоставлен фреймворком. И должно быть легко понять, какие функция, которую вы должны реализовать.

Это становится очень трудно сделать, если "что-то просто произойдет". Обычно это указывает на глобальное состояние в коде фреймворка. Либо в виде статических методов, либо глобальных/статических переменных.

"В какой момент срабатывает МОЙ код?"

Можете ли вы найти, где и как выполняется ваш контроллер? Обычно это будет не так просто. Эта мистическая точка обычно находится глубоко в объектном графике. Иногда даже в расширенном классе.

Такая ситуация делает вам очень сложно изменить среду, в которой был выполнен контроллер. Это также налагает строгие правила того, как должны выглядеть ваши методы контроллера.

Все это возвращает нас к тому, что в рамках true MVC следует улучшать процесс разработки, а не ограничивать ваши возможности.

"Предполагалось, что он/она сможет это сделать?"

Аутентификация авторизация может показаться отдельным аспектом разработки, но на самом деле в контексте MVC, это имеет тенденцию быть несколько сложным.

Многие фреймворки имеют некоторую инфраструктуру аутентификации/авторизации. Это повторяющаяся задача, и мы все сделали это до смерти, таким образом - это хороший кандидат на функцию, которую может предоставить фреймворк.

Но вот в чем загвоздка: большинство из них пытаются поместить авторизацию в ваши контроллеры, и они очень придирчивы к тому, как ее можно настроить. Это еще одно ограничение.

Вот к чему это сводится. Для любой фреймворк, он не должен требовать переписывания каждого контроллера только для добавления функциональности входа. Даже если вы проигнорируете нарушение OCP, это просто добавит вам еще один риск случайно что-то забыть.

..мои два цента

Cake и большинство фреймворков "MVC" - это то, что вы могли бы назвать "Пассивным представлением" MVC. Вот отличная статья, объясняющая: http://www.martinfowler.com/eaaDev/PassiveScreen.html

Иногда людям нужно отступить и взглянуть на "рамки" реальной жизни, из которых цифровой мир получил этот термин. Это может помочь объяснить его значение, несмотря на бесконечные онлайн-варианты, искажающие слово, чтобы соответствовать личным целям и принижать другие системы.

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

Итак, если у вас есть только одна страница портфолио - тогда вам нужен только крошечный набор инструментов. Если вы запустите следующий Facebook, то ваша "структура" будет совершенно другой.

Фреймворк, как следует из его названия, предназначен для поддержки структур - в данном случае вашего приложения. Общая (и печальная) особенность большинства фреймворков, которые вы видите, заключается в том, что они сами становятся навязывающими структурами, диктующими свой собственный способ разделения бизнес-логики, представления, маршрутизации/управления. Вы увидите код приложения, который выглядит так, будто вам нужна целая команда только для того, чтобы поддерживать то, что вы написали год назад. Похоже, что цель заключается в богатстве возможностей в рамки. Нет, это не так. Речь идет о предоставлении программисту свободы самостоятельно решать, какие компоненты приложения должны быть разделены и где должно быть разделение - до тех пор, пока задача может быть распределена между рабочей группой людей с их собственным опытом.

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

JavaServer Faces - довольно хорошая платформа полного стека для MVC. Он имеет хорошие компоненты представления, хорошие контроллеры с управляемыми компонентами, и для модели вы можете создавать бизнес-классы.