Можете объяснить как идет разделение MVC?
Я не очень хорошо понимаю, где границы каждой сущности в паттерне MVC. Рассмотрим паттерн на примере PHP. В типовом проекте у нас есть БД, php скрипты и html файлы.
По шаблонам вопросов нет - это html файлы с вставками кода (php, код шаблонизатора).
А что такое модель и где её границы? Модель это БД? Или модель это БД и php скрипты работающие с ней? А что тогда контроллер?
Читал примеры и определения на многих сайтах и так и не смог найти границу между моделью и контроллером.
Википедия
Модель предоставляет данные и методы работы с ними: запросы в базу данных...
Данные - то есть БД. Но и методы и запросы - то есть наши скрипты с классами, методами, запросами.
Контроллер обеспечивает «связь» между пользователем и системой.
Но и это наши скрипты - ведь они, по сути всё и делают - пишут в бд, выводят из бд.
Ответы (1 шт):
Всё познаётся на практике и вряд ли можно всё объяснить в ответе. Самое сложное - это модель. Поэтому начнём с контроллера.
Контроллер, да, как и написано - обеспечивает «связь» между пользователем и системой. Он должен принять запрос от пользователя, далее, в идеальном мире, дёрнуть какой-то метод "откуда-то" и, если нужно, вернуть ответ пользователю. В контроллере не должно быть никакой логики, как бизнес, так и простой. Все вычисления, логика, обработка данных, пересчёты, занесение в БД и пр, должно быть "где-то ещё" и результаты вернуть в контроллер, если это нужно для отдачи пользователю. Они такие должны быть по разным причинам, в т.ч. по причине что есть еще "Тестирование" и тестировать контроллеры сложно или невозможно порой. А вот тестирование логики в "чистом классе" вполне себе возможен. Проще мокать, стабать и прочие страшные вещи. Ещё в контроллере не должно быть логики и прочего взаимодействия с со слоями системы, т.к. это будет нарушать множество принципов: S из принципа SOLID, наверняка ещё и DRY будет нарушать, когда будут методы create/update, а также невозможно будет соблюсти модульность и сделать какой-то код независимый от MVC фреймворков в принципе. Слишком большая зависимость.
С моделью тоже тяжело. Если брать по ооооочень упрощённому и, например, фреймворк Yii2, то можно считать, что модель - это то, где происходит работа с БД, т.к. там модель - это буквально отражение записи в БД. Там же, в плохих руках, происходит и какая-то логика приложения (потому что люди не знают, что можно писать код по-другому). Однако модель - гораздно сложнее понятие. В идеальном мире модель - то, где происходит какая-то бизнес логика приложения, очень грубо сказано, конечно (Вбейте в поисковике DDD (Domain Driven Design)). Всё что происходит в моделе в таком контексте - не зависимо ни от фреймворка, ни от MVC, ни от чего-либо ещё.
То есть если немного подвести итог: модель - реализовывается бизнес логика, "чистые классы", которые подвергаются тестированию. Контроллер - берёт запрос от пользователя, с помощью впомогательных функций "очищает их" и проверяет (валидирует), направляет в модель, где происходит вся основная логика. Из модели, если нужно, возвращаются данные в контроллер и из контроллера обратно пользователю. Работа с БД в таком подходе происходит в РЕПОЗИТОРИЯХ, ссылки на которые находятся в модели. (Сейчас вас ещё больше запутаю ???)
В более непрофессиональных кругах модель - там где происходит и бизнес-логика и работа с БД и что ещё можно вообразить. Но контроллер всё равно всегда занимается своего рода распределением обязанностей. Например направить в одну модель → получить данные → направить во вспомогательный сервсис → получить даннные → отпраивть пользователю.
В ещё больше непрофессиональных кругах всё подряд пишут в контроллере
так и не смог найти границу
Как я писал - это происходит только с опытом. Начните с того, чтобы не писать никакой логики в контроллере, только "дёргать" вспомогательные сервисы и распределять работу между ними.
Если начать писать по DDD, то будет ещё сложнее определять не только эти границы, но и границы между слоями для того или иного действия ?