Авторизация в PHP + MVC, где осуществлять проверку?

>> за счет применение паттерна адаптер можно сделать много вложенных друг в дружку реализаций интерфейса

Может Вы имели ввиду "декоратор"?

xskif: не совсем. Если обертка что-то меняет во входных данных что бы адаптировать для внутренней части - это все же адаптер нежели декоратор.

Сергей Протько: Да что Вы. Адаптер адаптирует реализацию под требуемый интерфейс через композицию адаптируемого объекта, в то время как декоратор оборачивает объекты с идентичным интерфейсом для изменения или дополнения поведения методов.

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

xskif: бог с вами. Не в этом суть. Совсем не в этом.

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

Сергей Протько: на лицо подмена понятий. Middleware не обязательно быть адаптером, а Вы его сравниваете. Но, я соглашусь, если убрать адаптер из приложения - то оно, скорее всего, упадет, потому что интерфейс не соответствует. А вот декораторы должны быть взаимозаменяемы. От сюда вернемся к Вашему ответу. Вы предложили адаптерам делать то, для чего они не предназначены, оборачивать другие адаптеры бесконечное количество раз, называя декораторы адаптерами. Мне сразу вспоминается статья про ТТУКи. Собственно, поэтому я и придрался.

Middleware не обязательно является адаптером, более того, в большинстве случаев это совсем не адаптеры, скорее Chain of Responsibility. Для того они и подключаются через конфигурацию, чтобы добавить логику в Application Logic Layer, но их там может и не быть и приложение запустится, просто без той же аутентификации и авторизации.

xskif: Соглашусь.