Правильное наименование компонентов MVC в РНР фреймворках

[Фанат]

Вопрос на тостерре подтолкнул мою мысль, некоторое время уже работавшую в этом направлении.
И получилось у меня, что называем мы компоненты этого классического паттерна неправильно.
А правильно будет (по крайней мере, в случае с Ларавелью):

• Модели лежат в папке Controllers, при этом используя
  • ORM из папки Models для манипуляции с данными
• Визуальное отображение лежит в папке Views
  
• Секретарша лежит в routes.php.

И тогда всё сходится! Меня как раз смутили рауты в Ларавели, которые ничтоже сумняшеся используются в виде таких мини-рулетиковконтроллеров, которые берут на себя кучу задач - вплоть до авторизации!.
И меня давно уже смущало, что во всех фреймворках моделью называется тупо маппер таблицы из БД.

А вот если в голове названия переиначить, то всё сходится:
Раут - это тот самый тонкий контроллер, о котором все время говорили большевики, но который никто не видел.
Контроллер - это та самая толстая модель, которая отвечает за бизнес-логику!
Модель - ОРМ, которым и является.
Вью остаётся на месте.

Логично?

 

[Вурдалак]

Почему вместо вывода «мы неправильно работаем с моделью, перенося бизнес-логику в контроллер», ты сделал вывод «мы должны называть контроллер моделью, а модель — моделью-моделью»? Тебе проще заниматься подменой понятий?

Что касаемо Laravel: ну, грубо говоря, заменили один callable на другой, эдакий inlined controller, своеобразный синтаксический сахар. И что, ответственность роутера каким-то образом изменилась? Нет.

 

[Фанат]

«мы неправильно работаем с моделью, перенося бизнес-логику в контроллер»

А мы другого не видели просто. Когда мне покажут фреймворк, у которого запрограммирован тонкий контроллер и толстая модель (которая, при этом, НЕ является тупо инстансом ОРМ-а) - я буду рад не заниматься подменой.

 

[Вурдалак]

Содержимое контроллера и модели — это пользовательский код, а не код фреймворка, и только тебе решать, что там будет.

По поводу «инстанса ORM'а»: это просто потому, что ты знаком только с фреймворками, где предлагается Active Record в качестве ORM. Есть другой паттерн, Data Mapper, при котором модель выглядит как plain old PHP object:

class User {
    private $id;
    private $name;

    public function __construct($id, $name) {
        $this->id = $id;
        $this->name = $name;
    }

    public function getName() {
        return $this->name;
    }

    public function rename($name) {
        $this->name = $name;
    }
}

— это модель юзера. Ты где-то видишь ORM? Базу данных? Нет.

Кстати, я как-то писал уже про неправильное понимание слова «модель» и про MVC. Сущности, которые маппятся на таблицы — это не ещё не всё, что включается в понятие модели.

 

[Фанат]

Кстати, я как-то писал уже про неправильное понимание слова «модель».

Возможно, я туплю, но то, что происходит в Контроллере, на мой вкус как раз и описывается фразою

The central component of MVC, the model, captures the application's behavior in terms of its problem domain, independent of the user interface.

 

[Вурдалак]

Фанат, то есть ты запихал содержимое модели в контроллер и теперь объявляешь всем, что «Ба! Так контроллер-то — модель!»?

 

[Absinthe]

Есть другой паттерн, Data Mapper, при котором модель выглядит как plain old PHP objec

Это не модель, а DTO. Код, использующий эти DTO, и является моделью.

 

[Вурдалак]

Это не модель, а DTO. Код, использующий эти DTO, и является моделью.

Если бы это было DTO, я бы не писал rename(), я бы писал setName(). Я бы не мог туда запихать валидацию, например. DTO бы не имело методов, которые отражают поведение. А как бы выглядела твоя модель пользователя?

 

[Absinthe]

Если бы это было DTO, я бы не писал rename(), я бы писал setName(). Я бы не мог туда запихать валидацию, например. DTO бы не имело методов, которые отражают поведение. А как бы выглядела твоя модель пользователя?

В виде бандла с сервисом регистрации, набора сервисов аунтентификации, сервиса редактирования. Работающими с DTO.

 

[Redjik]

В виде бандла с сервисом регистрации, набора сервисов аунтентификации, сервиса редактирования. Работающими с DTO.

ага, на днях спорил с ребятами как раз, что DTO надо генерить и не трогать руками почти, а вот модельки писать уже в виде сервисов

один из аргументов - тестирование

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

 

[Вурдалак]

То, что вы называете DTO — это по сути http://www.martinfowler.com/bliki/AnemicDomainModel.html
То, о чём говорю я — это по факту что-то типа https://github.com/leopro/trip-planner/blob/master/src/Leopro/TripPlanner/Domain/Entity/Route.php

А да, by the way. HTTP-контроллеры в том репозитории относятся к presentation layer, что достаточно логично. HTTP — частный случай. Второй, вполне реальный, это CLI, например, или отдельная точка доступа для API со своими правилами.

 

[Redjik]

UPD. Перечитал фаулера... согласен.

Можешь на конкретном примере показать ситуацию (не тролю, реально интересует).
Пример с авторизацией.
Контроллер как сервис.

Мы в контроллер пихаем - реквест респонс.
В экшен... некую модель.
В каком виде приходжт в экшен модель.
И как мы производим поиск юзера - не в DIC же?
По идее в контроллере мы должны обратится к некой модели-репозиторию и попросить у нее на основании реквеста модель юзера.

 

[HraKK]

идет 2014 год, а мы тут обсуждаем что такое MVC и что такое ТТУК, грустно. Я думал это уже ушло в рудиментарное прошлое 2000-х.

И как мы производим поиск юзера - не в DIC же?

 

[hell0w0rd]

Redjik, посмотри на security от симфони) https://github.com/symfony/security-core