Скажите, зачем выносить loginUser() и logoutUser() в базовый класс контроллера? Просто поглядываю на код как на пример и мне не понятно зачем это. Не будет ли лучше сделать это в контроллере User?

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

Спасибо, суть вроде понял. И сразу появился вопрос.
Раз сессия это сущность, которая может принять множество обликов (как Вы упамянули OpenID, стд сессии итд) то логично создать сущность сессии.
Еще есть сущность пользователя, которая выполняет вход/выход итд, и которая агрегирует сущность сессии (точнее композирует, если можно так сказать) и работает с этой сущностью.
А контроллер User или любой другой уже будет работать с сущностью пользователя.

Правильно будет если я реализую такую логику?

Bio man
Не путайте модель и контроллер. Контроллер отражает логику приложения по работе с моделью.
По поводу сессии пользователя - да, сущность "пользовательская сессия", по-хорошему, должна быть создана и должным образом оформлена, иметь требуемые методы (в том числе, если это нужно - авторизацию посредством запрашиваемого провайдера). Посмотрите Zend - там, если не ошибаюсь, работа примерно в таком исполнении ведется.

Так я не путаю вроде.
Я о том, что есть модель User, которая работает с моделью Sessions и БД. А с этой моделью можно работать в любом контроллере.
Так будет корректно?

Может я сильно увлекся в этой теме, не совсем ведь по теме... Может перенести в отдельную?

Сами хоть поняли чего понаписали?

caballero
да а как по вашему надо?

Bio man, ну имхо класс для работы с сессиями и базой это не модели а часть функционала приложения, ядро приложения скорей или его часть, а модель User взаимодействует с ними.

sKaa как по мне так модели. только юзер посредник, который берет данные с БД и сессии...

надо что?
правильно сформулированный вопрос уже половина ответа.
В данном случае чтобы получить ответ нужно грамотно сформулировать задачу.


с этого и начни - сформулируй шо сие такое модель. Чтобы это не было чем то расплывчатым по которому непонятно что к нему относится.

В общем, следует прочитать вот от сюда, что бы понять с чего началось...
Правильно ли сущность пользователя вынести отдельно как модель и в нем реализовать методы login и logout, вместо того, что бы в базовом контроллере делать эти методы, как в примере.

Модель в моем понимании это красивая девушка и еще это класс (если говорить в ед. числе), который отвечает за ввод/вывод данных, например, в БД. Есть тонкие модели, что является просто массивом данных.

Опять же что такое модель и что такое в данном контексте базовый контроллер.


а еще под моделью можно понимать всю структуру данных проекта лежащую в БД. Как по мне было бы проще не употреблять термина модель вообще.

Тот что в примере Евгения. Посмотри самый первый пост на самой первой странице

Смотреть лень, я так понимаю что это классическое :