Что делает фреймворк «настоящим» фреймворком MVC? - PullRequest
20 голосов
/ 18 июня 2009

Когда я читаю онлайн-обсуждения фреймворков MVC, я слышу множество комментариев, направленных на PHP-проекты, такие как Cake, Code Igniter и Symfony, от разработчиков Java / .NET в духе «это умные хаки, но не настоящие MVC».

Итак, что делает что-то «настоящим» MVC-фреймворком; то есть, что является примером платформы .NET или Java MVC, которая делает вещи иначе, чем Cake, Code Igniter, Symfony и т. д., и что это за разные вещи? Это просто отсутствие в PHP принудительной ориентации объектов, требующей начальной загрузки, или это что-то еще?

Я знаю, почему язык PHP "отстой", меня больше интересуют различия в реализации и / или использовании MVC.

Ответы [ 8 ]

13 голосов
/ 18 июня 2009

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

Многие PHP-фреймворки пытаются использовать философию Ruby on Rails «самоуверенное программное обеспечение», поэтому для правильного функционирования Model и View вместе требуется, чтобы оба соответствовали определенной реализации. То есть классы должны быть названы определенным образом, файлы в проекте должны быть организованы в соответствии с определенной структурой каталогов, нотации в сценариях View должны соответствовать соглашению и т. Д.

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

2 голосов
/ 14 июня 2012

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

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

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

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

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

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

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

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

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

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

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

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

«Должен ли он / она быть в состоянии сделать это?»

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

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

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

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

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

2 голосов
/ 26 ноября 2009

Настоящая структура MVC не имеет слоя M (odel). CakePHP и его друзья имеют несколько умных классов для доступа к базе данных, которую они называют Model, оставляя большую часть обработки данных контроллеру.

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

2 голосов
/ 18 июня 2009

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

1 голос
/ 19 июня 2009

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

0 голосов
/ 19 февраля 2010

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

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

0 голосов
/ 19 июня 2009

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

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

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

0 голосов
/ 18 июня 2009

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

...