Где в MVC паттерне выводить заголовки и включать сессии?

Question

[onatskyi_d]

Здравствуйте. Где в MVC выводить заголовки и подключать сессии (session_start и прочее)? В каком из классов, View или Controller?
Или как вообще это дело реализовать?

Только вчера сел изучать MVC, не кидайте сильно ботинки в мою сторону))

Comments

[Nikita Krasnikov]

Для старта посмотри и изучи mvc фреймворк Yii2, он простой и для новичка сгодится. Поковыряйся в исходниках фреймворка, посмотри как все устроено, пробежись дебаггером по основным методам. Обязательно изучи документацию.

Если нужен посложнее фреймворк, то посмотри в сторону Laravel.

[Decadal]

Евгений Ромашкан, ой, вот эти вот советы типа "делайте как удобно", где вы их берёте? Даже если бы MVC было придумано в пятом тысячелетии до нашей эры, лучше писать ориентируясь на него, чем по своему наитию писать код, который устаревает раньше, чем вы его сделаете рабочим. Потому что MVC решает проблемы, а интуиция неопытного человека их создаёт.

[Евгений Ромашкан]

Decadal, 1. Какие проблемы решает MVC? Много людей это понимает, или просто делают единственное что умеют? Почему не MVVM?
2. По MVC вьюха сама себя отрисовывает и асинхронно кидает ивенты контроллеру, готовый преобразует их в синхронные вызовы модели, на изменения которой подписана вьюха, где вы в пхп такое видели, который по сути тупо на реквесты отвечает?)

[Decadal]

Евгений Ромашкан, MVC решает проблему смешения логики, отображения и управления запросами, особенно это актуально для пхп где первое чему учатся новички - всё смешивать.
Вы говорите "почему один подход а не другой" так как будто знаете, какую задачу решает человек, задавший вопрос. Но человек учит конкретный подход, и это MVC, а не MVVM. Если бы вопрос был про MVVM, я бы отвечал в рамках этого подхода.
К слову, если бы вы обосновали, почему лучше MVVM а не MVC, то даже если бы я был не согласен с вами, ничего бы не написал. Но вы советуете "писать как удобно", господи, вы точно понимаете как это будет выглядеть?

"По MVC вьюха сама себя отрисовывает"

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

[Евгений Ромашкан]

Decadal, Сначала новички поначитаются всягой фигни на Хабре и тостере про MVC а потом вместо того чтобы думать о зависимостях и связности задают вопросы аля "где бы миграции впихнуть, в контроллер или модель?".

MVC не сообщает подробностей, что, где и что именно рендерит

А я считаю что сообщает, где будем правду искать?)

[Decadal]

Евгений Ромашкан,
"А я считаю что сообщает, где будем правду искать?)"
живите с ней, вас переубеждать я не заинтересован

"Сначала новички поначитаются всягой фигни на Хабре и тостере про MVC а потом вместо того чтобы думать о зависимостях и связности задают вопросы аля "где бы миграции впихнуть, в контроллер или модель?"."

ну да, пусть лучше вас на тостере прочитают и будут всю жизнь писать костыли

[Евгений Ромашкан]

Decadal, Костыли?)
А писать MVC/*любой другой баззворд* не понимая что это такое не костыли?

Если вы считаете что гнаться за мифическим MVC(которым почти никто не интересуется дальше статей на хабре от школьников) важнее чем задумываться о качестве архитектуры и о том в чем оно измеряется - ок. Не мне вас переубеждать.

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

Разделение на слои нужно исключительно чтобы учитывать направление зависимостей. Без этого оно не имеет смысла.

Answer 1

[Decadal]

Работа с сессиями и заголовками происходит в контроллерах или вспомогательных классах, которые контроллер использует.
Почему - потому что сессии и заголовки это вопрос к тому, как обрабатывать запрос от пользователя, а контроллеры именно этим и занимаются. Чтобы легче понять, почему так, представляйте, что контроллеры работают не только с HTTP запросом, но также могут использоваться для обработки консольных команд, где ваши заголовки и сессии вообще не нужны. Будет много проблем, если вы внедрите работу с сессией в слой моделей, на том уровне, где не сможете легко и просто (и без костылей) понять, была ли это консольная команда или запрос из браузера.

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