Движок на ООП с использованием паттерна MVC

[vitus]

Вот,тут интересно!
Привет всем. После нескольких лет использования PHP только для конфигурации, подъёма и стриминга данных в другие приложения, у меня возникла необходимость сделать сайт, который будет использовать данные этих приложений (и желательно уже работающие классы модели). Естественно после большого перерыва решил посмотреть на текущее состояние дел с фреймворками, нашёл то о чём говорит Фанат и огорчился ;( .
Действительно MVC в вэбе трактуется как-то странно. Возникает даже вопрос о его целесообразности. Ведь задача этой триады - только отделение представления от модели как-раз для множественного её использования, а фреймворки пытаются мне навязывать интерфейс модели - в моей ситуации это дурь и оверхед. Возможно я неправ и просто не умею их готовить?

зы:Огорчение привело к написанию очередного велосипеда... Фреймворка мечты (двупроходный 'HMVC' - если это вообще MVC) сейчас пишу рулилку и ненарадуюсь, возможно где-то меня ждёт разочарование...

 

[fixxxer]

Класс Юзер екстендс Модел

class User extends Model - вот это слово Model, чтобы не смущало, выбросим и напишем class User extends ActiveRecord. Дальше сделаем рядом пачку классов - репозиторий, возвращающий коллекции User-ов по каким-то критериям, сервисы для регистрации-аутентификации. А в контроллере просто напишем три строчки.

Делать по-другому - это идти против гайдлайнов фреймваорка

По так называемым гайдлайнам так называемого фреймворка надо кругом писать Yii::$app->request. В задницу такие гайдлайны, чо.

На ларавеле можно писать по-разному, он мультипарадигменный. Про симфони2 вообще тут уж нечего говорить

в каки-то воображаемых проектах

Вот у меня тут в сторме воображаемый проект щас открыт.

 

[Вурдалак]

hell0w0rd, вот в оконных приложениях в MVC view обновляется моделью, а не controller'ом. В web MVC controller — это по сути view. Symfony Command ты тоже контроллером называешь? К тому же ты не напрямую с model из контроллера работаешь, service layer — это не модель. Если значения терминов настолько размыты, то нахрен такую терминологию.

 

[Вурдалак]

Возможно я неправ и просто не умею их готовить?

Да, ты не прав и не умеешь их готовить.

 

[vitus]

hell0w0rd, вот в оконных приложениях в MVC view обновляется моделью, а не controller'ом.

поправочка - может обновляться, а может и не обновляться.

В web MVC controller — это по сути view.

по сути он само ПРИЛОЖЕНИЕ , имхо - не факт что view.

К тому же ты не напрямую с model из контроллера работаешь, service layer — это не модель. Если значения терминов настолько размыты, то нахрен такую терминологию.

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

 

[vitus]

Да, ты не прав и не умеешь их готовить.

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

 

[Вурдалак]

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

 

[hell0w0rd]

Почему сервисы - это не модель?) Пишешь ли ты в базу, шлешь ли в твиттер, отправляешь ли email - это все модель.

 

[Adelf]

Вот тоже заколебался на работе обьяснять. Веду курс там по ASP.NET MVC. Попытался прикола ради обьяснить, что нифига это не MVC. И полилось. Ты не прав! Это MVC! Привожу факты.. например youtube у которого данные(видюшки) в чистом виде доступны для скачивания без всяких контроллеров и всякие сервисы это используют. REST сервисы тоже. На веб эта парадигма ложится с таким натяяягом, что проще просто забыть об MVC и просто строить приложение нормально его архитектуря, юзая SOLID принципы. И будет вам PROFIT. Не верят...

Upd: и да. Контроллеры я теперь стараюсь на этих лекциях называть RequestResponser'ами. Проще понять смысл.

 

[Вурдалак]

Почему сервисы - это не модель?

Мне кажется, ты путаешь domain model services и service layer. Первое — модель, второе (Command Handler + Commands, Use Cases) — это не модель.

На примере того же TripPlanner:
https://github.com/leopro/trip-planner/blob/master/src/Leopro/TripPlanner/Application/UseCase/UpdateLocationUseCase.php — это часть service layer, который описан у Fowler'а.
https://github.com/leopro/trip-planner/blob/master/src/Leopro/TripPlanner/Domain/Contract/TripRepository.php — вот это, например, domain model service. Но на domain layer реализация такого сервиса нас не интересует, только контракт.
https://github.com/danberghjohnsson/qi4j-tutorials/blob/master/cargo/src/main/java/org/qi4j/tutorials/cargo/step1/OverbookingPolicy.java — вот это, например, тоже domain model service.

 

[vitus]

Вурдалак, - похож, да.
Ниодин из рассмотренных мной фреймворков не удовлетворяет моей задаче, Мне нужны реюзабельные, настраиваемые контроллеры, собранные в иерархии на страничке, обрабатывающие только запросы направленные непосредственно им и легко перемещаемые в любое другое место на страничке, мне не нужен орм, не нужен уровень сервисов, мне не нужен class User extends Model, у меня уже есть class User, нафига мне ваш фреймворк?

 

[Adelf]

реюзабельные, настраиваемые контроллеры, собранные в иерархии на страничке

Не ломай мой мозг!

 

[Вурдалак]

Вурдалак, - похож, да.
Ниодин из рассмотренных мной фреймворков не удовлетворяет моей задаче, Мне нужны реюзабельные, настраиваемые контроллеры, собранные в иерархии на страничке, обрабатывающие только запросы направленные непосредственно им и легко перемещаемые в любое другое место на страничке, мне не нужен орм, не нужен уровень сервисов, мне не нужен class User extends Model, у меня уже есть class User, нафига мне ваш фреймворк?

Чувак, после этих слов в разделе «Теория программирования»:

даже не желаю учиться

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

 

[vitus]

Не ломай мой мозг!

Мне кажется, ты путаешь domain model services и service layer. Первое — модель, второе (Command Handler + Commands, Use Cases) — это не модель.

Повторюсь: всякие ярлыки (и догмы) - зло, потомучто начинают подменять понятия и доводят адептов до абсурда.
Второе - это фасад к модели чтобы модель научилась делать то что не умела, для контроллера оно неотличимо от модели.

 

[vitus]

Чувак, после этих слов в разделе «Теория программирования»:

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

Фу, как не красиво, молодой человек, что Вас так задело, право? Не стоит нервничать и отвечать на риторические вопросы в приличном обществе .

 

[hell0w0rd]

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

 

[hell0w0rd]

vitus, https://github.com/FriendsOfSymfony/FOSUserBundle - вот ребята сделали максимально абстрактный на все случаи жизни бандл для управления пользователями. Как думаешь, там просто так 200 незакрытых вопросов и 70 PR?

 

[vitus]

vitus, https://github.com/FriendsOfSymfony/FOSUserBundle - вот ребята сделали максимально абстрактный на все случаи жизни бандл для управления пользователями. Как думаешь, там просто так 200 незакрытых вопросов и 70 PR?

Думаю что не просто так, думаю что "абстрактный на все случаи жизни бандл для управления пользователями" обязан иметь всё это.

 

[vitus]

Не ломай мой мозг!

RequestResponser - так оно действительно правильнее, их ещё сервлетами называют и другими разными словами, они в том смысле контроллеры, что находятся между моделью и видом. Его не надо писать на все случаи жизни, он должен быть настолько прост (прозрачен, понятен) насколько это возможно, это его ответственность обеспечить разбор запроса, формирование данных из модели (прямо или косвенно) и определить - что с этими данными дальше делать (как рисовать например). У меня получилось даже что темплеты разрабатываются не для модели (предметной области) а для "контроллеров" и да, никто не мешает сделать "контроллер" в виде триады MVC и у него могут быть свои собственные настройки и он сам тоже вполне себе модель для кого-то другого.

 

[Vital7]

• View - это весь внешний вид страниц. Фактически, это набор HTML-файлов, каждый из которых отвечает за отдельную страницу
• Model - это набор низкоуровневых функций. Например, по работе с базой данных, по аутентификации пользователей, по отправке e-mail сообщений и так далее. Другими словами, это служебные функции, реализация которых, вообще говоря, скрыта.
• Controller - это связующее звено между View и Model. Сюда приходят данные из View (например, при отправке форм), сюда же приходит ответ от Мodel, и именно Controller решает, какой шаблон выбрать.
  Вообще, я так понял, суть этого подхода заключается в том, что отделить работу дизайнера и программиста. Если это не так, поправьте меня.

Далее, в этом подходе имеются две проблемы. Первая, мы не сможем совсем избежать PHP-кода в View (простой цикл заведет нас в тупик), а там, напоминаю должен находиться только HTML. И вторая, Controller решает, какие блоки выводить на странице, это задача дизайнера, но он в свою очередь отвечает лишь за View.
Если эти две проблемы игнорировать, то в целом, MVC не так уж и плох? Вообще, я бы чистый MVC никогда не стал бы использовать, но все остальные подходы идут от него вроде бы.