Pull to refresh
114
0
Протько Сергей @Fesor

Full-stack developer

Send message
Дело в том, что модуль MVC скорее относится к ядру приложения

  1. Это не так.
  2. если у приложения есть "ядро" — с декомпозицией явно пошло чтто-то не так.

Да, в MVC есть цепочка преобразования

Вся проблема в том что в вашем MVC эта цепочка есть, в моем MVC ее нету, а у кого-то что-то другое. Потому смысла обсуждать MVC нет ибо каждый подразумевает под этими тремя буквами что угодно.


И да, судя по тому что я вижу вы эти три буквы воспринимаете как три слоя — хотя это не так. все эти три буквы ложатся в один слой.


Ну и опять же — всегда можно обратиться к первоисточнику. Возможно вам будет интересно.

ViewModel тут в контексте «модель данных для вьюхи» а не ViewModel из MVVM.

Ну то есть опять же, MVC это исключительно про UI. Про то как формируется представление данных пользователя, конвертация ментальной модели. Все остальное приложение выходит за рамки MVC, чего многие не понимают. Для многих «модель это штука которая ходит в базу», из чего следует что логику нужно ложить в контроллеры. И в итоге вся идея с разделением ответственности как бы умирает.

что до ивентов, в оригинальной MVC 1978-ого года выпуска «моделька» это была не тупая структура данных, и вьюшки подписывались на события, и поток данных шел строго по кругу, а не как сейчас, когда контроллер действует больше как презентер из MVP (хотя мне больше нравится сравнение с mediating controller MVC, или MVA, так как концепция мидлварь туда вписывается больше).

Короче мое мнение — MVC это такая штука, которую не стоит даже объяснять бэкэндщикам. Вопросы разделение ответственности можно подругому объяснять. Не вводя абстрактных терминов типа «модель». Ну или коль уж вводить надо объяснять что модели это модели, это не слои и не уровни приложения. И что все элементы MVC ложатся в один слой. Presentatio layer.
Ник на рэддите [объяснял](https://www.reddit.com/r/PHP/comments/9j2oel/rfc_about_typed_properties_has_been_accepted/e6o94hd/).

Ну и опять же, достаточно обратиться к документации (что вы обязаны делать когда изучаете новый для вас инструмент): Doctrine Documentation: Quoting Reserved Words


Вообще очень плохая идея изучать Doctrine по огрызкам из документации к симфони. И еще более плохая идея — изучать symfony по огрызкам на хабре.

сменить на «uuser»

users тогда уже… ужасные кастыли на ровном месте.


PostgreSQL 9.3

уже как бы 10-ая версия, и судя по контексту вы новый проект делаете.


следует учесть это и в шаблонах

не следует — вы можете название таблицы явно в меппинге указывать, как никак вы ссылаетесь на поля объекта а не на табличку в базе.


Итого — вам не стоит юзать доктрину. А с postgre 9.4+ в целом значительно падает необходимость в подобных инструментах (за счет jsonb, можно целиком стэйт хранить одним полем и отпадает любая необходимость мэпить связи)

пожертвований никаких не было

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


Для того что бы "просто добавить… электронный вид" нужны не маленькие вложения, и увы на сегодняшний день это не будет востребовано. Нет, дело не в конфликте интересов с бизнесом а в банальном отсутствии финансирования. Потому краудфандинг в целом неплохой способ добиться этого.

Перегрузку в C++ использую постоянно, в том числе в конструкторах…

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


о том, что могут быть проблемы

когда-то был баг с функцией которая делала хэш от объекта, но опять же вам никто не мешает сделать свою мэпу которая как-то по особому вычисляет хэш. Это не что-то такое что часто используется в php. ну и опять же, есть php-ds который делает разруливание хэша более явно.


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

Множественное наследование классов прекрасно заменяется интерфейсами. А потому не вижу проблемы. Что до виртуальных функций — немного непонятно что именно вам нужно. Перегрузка методов в наследниках как бы существует. Абстрактные методы тоже.


В целом ваши притензии больше тянут на "непривычно" нежели "существенные проблемы". Что странно ибо существенных проблем у php много.

Перегрузка функций и методов в естественном виде.

с этим есть определенные проблемы:


function foo(string $bar, string $baz);
function foo(int $bar, int $baz);
function foo(string ...$barBaz);

foo('0', '1'); // какую из трех сигнатур должен вызвать php?

в целом перегрузка методов была бы полезной штукой, но и без этого можно вполне себе жить (просто не так удобно).


Сложные ключи ассоциативных (хеш) массивов.

http://php.net/manual/en/class.splobjectstorage.php — и дальше по аналогии. В целом обычно этого достаточно.


Наследование и полиморфизм, как в C++.

  1. наследование классов не очень полезная фича. В этом случае полностью абстрактные виртуальные классы как в вашем любимо C++ — это интерфейсы. И их можете спокойно множественно наследовать.
  2. наследование стэйта — очень простой способ выстрелить себе в ногу.
  3. friend классы не нужны.
  4. Если вы про темплейты (параметризованный полиморфизм) — дженерики появятся рано или поздно, но что-то подсказывает мне что вы не о них. Да конечно это не такая мощная вещь как темплейты но и то хорошо.

Опять же — PHP не претендует на звание хорошего языка. Увы.

Маск решительно выступал за бренд X.com вместо PayPal

а еще топил за сервера на windows NT вместо солярисов. Занятно но победил linux.

А вот это на много реальнее, когда проект упирается в PHP.

Покажите выборку по которой вы оцениваете вероятность различных сценариев. Ибо в моей практике "проект" практически никогда не упирается в PHP (опустим отвращение разработчиков при работе с оным, особенно тех кого избаловали языки с нормальной системой типов и стандартной библиотекой). Да, бывает так что часть задач внезапно сильно упирается в CPU или в I/O (тут как бы на php тоже можно до определенного момента жить, но проще взять что-то с более богатой экосистемой), но обычно это не более 20% от функционала проекта и есть масса вариантов как это все перевести.


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


Часть проекта — да можно переписать, планомерно переводить проект — можно. И тут важно что бы проект в целом был слабо связан, с чем у Yii не все так гладко.


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


p.s. а пилить микросервисы на yii это просто дурная идея. Особенно когда "микросервисная архитектура" у проекта мотивирована тем что разработчик насмотрелся докладов на эту тему и решил попробовать обмазаться кубернетисами и усложнить инфраструктуру, даже если все это первые 3-4 года жизни продукта будет не нужно и будет только усложнять жизнь разработчикам. Ну и опять же чаще можно встретить "микросервисы" где вызовы методов заменили http вызовами и теперь думают что у них связанность меньше стала.

признак плохого дизайна кода.

мне кажется в вашей логической цепочке пропущены важные штуки. Если объекты будут использоваться вместо массивов (коллекции например) как это избавит код от map-ов и редьюсов? Что будет внутри вместо?


Словом, поясните свою мысль.

Расскажите мне как вы проводили эстимацию затрат и масштабов проблем?
Ну в таком ключе «это» есть в любой ORM которая умеет в lazy + eager загрузку данных.
А зачем вам id само по себе? Что вы с ним будете делать?

хранить, на чтение у меня другие штуки. ORM на чтение не нужна.

> где это бы требовалось

То есть вы не видели систем где требуется «что бы работало»? Статический анализ это просто один из вариантов как можно производить верификацию, это не серебрянная пуля, тесты всеравно писать придется. Но от тупых ошибок избавиться хотелось бы в компайл тайме.

Да и опять же. имея интроспекцию можно много тупого кода удалить.
Было бы здорово увидеть реализацию подобной возможности для PHP.

Doctrine и DQL.


select sales.date, sales.amount, customer.name 
FROM App\Sales sales JOIN sales.customer customer

но в целом я бы не назвал это прям таким удобным (потому что в большинстве случаев я бы хотел видеть в объектой модели айдишки а не целые сущности). Основная проблема большинства квери билдеров — манипуляция строками и мутации, что делает невозможным ни верификацию типов ни прочие прикольные вещи. Про композицию вообще молчу.

> И каждый раз изобретая очередной «велосипед» может родиться умная и конструктивная дискуссия.

А толку? Ну то есть… смотрите. Вы написали велосипед. Причем не просто велосипед, а примерно такой же как пишут его сотни других разработчиков ежегодно (если не еженедельно). На хабре подобные велосипеды постят раз в пол года примерно (вот типа одинаковые по работе с базой), и будут продолжать постить. «Форум разработчиков» же.

Так вот, польза от этих «дискуссий» в общем только для автора велосипеда. потому что он не счел необходимым погуглить другие велосипеды и происходящие там «дискуссии», иначе одинаковых велосипедов было бы меньше.

А потому — толку для сообщества нет от слова совсем.
Нет, почитать стоит. Особенно в варианте PoEAA фаулера (вместе с другим подходами, разбором их плюсов и минусов и т.д.)
А о том, что со временем и сами названия меняются — тем более.

от того что вы юзаете code igniter термин query builder своего значения не поменял ни разу. Это штука которая позволяет вам строить запрос. причем за выполнение этого запроса или за работу с result set оно уже не отвечает.


Причем, для того что бы вы могли с result set работать вам нужна какая-то информация о запросе (интроспекция) и проще всего это сделать добавив свой строитель запросов который будет эту инфу предоставлять для других компонентов вроде мэпперов каких и т.д. Ну и что бы не писать что-то типа $db->execute($query) и т.д. можно скрестить это дело и с коннекшен менеджером.


Но это просто конкретное решение конкретной библиотеки и никакого отношения к терминологии все это не имеет.


Что до "конечного пользователя" — проблема штук типа CI ActiveRecord в том что это создает ограничения применимости решений. Иногда хочется и не через PDO поработать а через какой-то асинхронный драйвер на модных нынче свуле, и оказывается что 99% всех квери билдеров это подкопирку содранные друг к друга куски гуано которые так просто не реюзать.

раньше понятия QueryBuilder и ActiveRecord отличались от нынешних

Нет, раньше query builder как подход и active record как паттерн были тем же чем они являются сегодня. Это как бы суть названий и терминов — если они часто меняются, и у них нет четкого определения — то надо придумать новый термин с четким определением и перестать юзать что-то что вводит в заблуждение людей.


Причина по которой под ActiveRecord понимают все что угодно произрастает из безграмотности людей и подмены понятий (когда "паттерн" какой-то или идею подменяют конкретной библиотекой).


и люди писали самодельные велосипеды на файлах.

в 70-х? да, было такое. только тогда небыло ни mysql ни php да и концеп SQL-я только только зараждался. И нет ничего плохого в хранении данных в файлах, просто это сегодня имеет смысл только если вам надо специализированное хранилище (и вряд-ли вы что-то такое будете на php писать, хотя можно).

Information

Rating
Does not participate
Location
Минск, Минская обл., Беларусь
Date of birth
Registered
Activity