Я искал вокруг, но, похоже, нет четкого консенсуса, по которому лучше. В настоящее время все HTML-формы на сайте указывают на один файл PHP. Каждая форма имеет скрытый ввод, определяющий действие (например, «пользовательский логин», «выход пользователя из системы»), а также методы PHP-файлов.
Поэтому мой вопрос: должен ли я указывать каждую форму обратно на себя, связанные формы в один файл или все формы в один файл? И с точки зрения MVC, должна ли обработка выполняться в контроллере или форме?
Должен ли я указывать каждую форму обратно на себя, связанные формы в один файл или все формы в один файл?
Вы должны указать все на index.php , который затем делегирует другие компоненты (контроллеры в терминах MVC), чтобы позаботиться о обработке. Затем контроллер определит, какой вид он хочет отобразить. index.php будет в этом случае тем, что мы называем фронт-контроллером . ( примечание : ниже я рекомендую ZF1 как обучающую платформу. ZF1 имеет класс «front controller». Некоторые люди могут утверждать, что THAT является первым контроллером, а index.php – это то, что они называют сценарием записи . На мой взгляд, это является лишь вторым «фронтовым» контроллером. Тем не менее, оба мнения противоречат друг другу, поэтому сделайте свое мнение).
И с точки зрения MVC, должна ли обработка выполняться в контроллере или форме?
С точки зрения ООП в первую очередь: объект является единственным, кто знает, как проверять свои собственные данные ( принцип самоограничения ), поэтому форма должна проверяться. Если речь идет о модели, модель должна вызываться либо контроллером, либо формой – это вопрос вкуса. Независимо от того, в каком направлении применяется тот же принцип: вы загружаете модель данными и вызываете ее метод проверки.
Как вы могли заметить, класс Form является Model .
Не позволяйте себе обманываться шумихой под названием MVC. Уважайте принципы ООП прежде всего .
Что касается MVC: шаблон MVC говорит: контроллер только координирует другие компоненты, например, он принимает вход, создает экземпляр формы и вызывает метод проверки формы.
Я советую вам использовать структуру, чтобы лучше видеть, как все эти части работают вместе. Лучше всего было бы zend framework 1, что мало связано с реальными требованиями к жизни, но это шедевр с точки зрения моделей и практик.
Возможно, ZF2 изменит эту ошибку с помощью дополнительного фронтального контроллера.
Глядя на другие ответы, я чувствую необходимость уточнить терминологию, используемую в моем ответе:
Model – это модель. Существует много документации о MVC Form является подклассом Model . Он выполняет валидацию. Он также может иметь метод Form::__toString() который отображает HTML-форму в представлении (V в MVC) Чтобы повторить, общий поток выполнения будет выглядеть так:
<form action ... Controller координирует все действия, вызывая Model::validate() одной или многих моделей (включая Form , которая также является Model ) Controller render() попытку render() представления (html-файл), который может содержать вызов Form::__toString() , и в этом случае Form является гибридом Model и «рендеринга». Вот и все, в принципе. Различные структуры имеют разные потоки данных / выполнения. ZF1 выглядит так: http://www.slideshare.net/polleywong/zend-framework-dispatch-workflow
В условиях MVC ваша обработка должна выполняться в контроллере. У вас не должно быть логики обработки в вашей форме (вид). Независимо от того, есть ли у вас другой контроллер для каждой формы, зависит от вас. Например, у вас может быть один контроллер, который принимает все представления форм и выполняет некоторую общую обработку (например, обнаружение csrf), а затем вызывает другие контроллеры для каждой формы. Кроме того, у вас может быть один контроллер, который загружает требования валидации из базы данных и ведет себя по-разному в зависимости от того, какая форма была отправлена.
В условиях MVC, когда все формы указывают на один скрипт, вы имеете Front-Controller для форм . Существует один контроллер, который обрабатывает запросы формы.
Должен ли я указывать каждую форму обратно на себя, связанные формы в один файл или все формы в один файл?
Это зависит от ваших потребностей и дизайна, возможно, от архитектуры вашего сайта.
И с точки зрения MVC, должна ли обработка выполняться в контроллере или форме?
Обработка в MVC обычно происходит внутри контроллеров (только слегка) и моделей (тяжелая обработка). Поэтому, если вы ищете примерную реализацию дизайна MVC, у вас, скорее всего, будут модели моделей , которые используются контроллером (-ами) .
Это обеспечит более гибкое использование форм, и вы не будете дублировать код для обработки форм в своем приложении.
По-моему, вы должны использовать один файл для каждой цели. То же, что и структура mvc, это хороший подход для программирования, и это будет полезно, когда ваш код становится очень сложным.
Вы сомневаетесь, что это касается шаблона Front Controller . По-моему, вы ничего не теряете, указывая на какой-то определенный сценарий, но выигрываете гибкость, выполняете определенные действия, не повторяя (и, вероятно, не устраивать в каком-то месте) эти действия.
Поэтому я бы рекомендовал указать все формы на один скрипт.
Btw. это контроллер, который обрабатывает обработку формы с точки зрения веб-MVC.
Следуя из моего комментария на ответ Флавиуса …..
Объект, инкапсулирующий форму, должен использоваться как для представления формы пользователю, так и для получения данных, отправленных обратно от пользователя. Использование двух разных кодов для работы с одним и тем же набором данных подрывает принцип инкапсуляции. Подумайте, имеет ли ваша форма входа имя и поле пароля. Если вы решите, что хотите обработать хэш-код sha1 вместо исходного значения, вам может потребоваться изменить 2 бита кода в двух разных местах!
Это не означает, что оба экземпляра объекта формы должны быть реализованы в одном URL-адресе; рассмотрите PHP-запросы 'require' и auto_include.
Если несколько наборов ввода мультиплексируются по одному и тому же пути URL, это называется шаблоном переднего контроллера.
Есть преимущества и проблемы с Front Controller и более распределенным подходом.
Передний контроллер:
Non Front Controller: