Read models naming

grigori

( ͡° ͜ʖ ͡°)
Команда форума
у вас разные контексты в разных пространствах имен?
 

Вурдалак

Продвинутый новичок
у вас разные контексты в разных пространствах имен?
А я не про BC.
Они в разных слоях, обе модели друг про друга ничего не знают, и семантически и технически у них разные задачи. Даже слово «модель» к ним применима в разных смыслах.
В противном случае в API ты отдаёшь не «продукт», а «карточку продукта».
Когда удивлённый пользователь API спросит почему именно «карточка», то ты ему расскажешь, что это конфликтует с именем domain model.
Да и domain model со временем переименуешь, ведь на самом деле продукт на полках, а это — «КомпьютернаяМодельПродукта».
 

WMix

герр M:)ller
Партнер клуба
если на секунду вспомнить о graphql, то думается, что в php read-model должна быть основана на базе ассоциативного массива (к тому что клиент просил только определенный набор атрибутов). хотя возможно массив это конечное представление.
 

WMix

герр M:)ller
Партнер клуба
я так понимаю, что в этом случае (graphql) результирующая модель обрабатывается клиентом и от того что в пхп были бы generic-и или была бы возможность массивы типизировать, клиенту легче не становится.
задача только добыть и связать данные, все для связки (момент вычислений) по идеи и так храниться где-то в обьектах типа relation, а остальное как есть так и отдавать нужно. максимум что надо сделать, это проверить на разрешение запрошенные аттрибуты считывать.
 

fixxxer

К.О.
Партнер клуба
А при чем тут клиент? Может, у меня тупой клиент, и все рендерится на сервере. Какое это отношение имеет к read model?
 

WMix

герр M:)ller
Партнер клуба
тупой клиент врятли на graphql общаться будет.
но если в твиг забабахать метод "graphql"
PHP:
{% set user = graphql('{me{name}}') %}
<h1>{{user.name}}</h1>
то все опять на своем месте

Какое это отношение имеет к read model?
ну я так понимаю что graphql('{me{name}}') должно возвращать "read model"
 

Юрий Быков

Новичок
Расскажите как будете использовать read-модель. Она действительна нужна в проекте? Может имеет смысл выдавать некий массив из обычной модели или сразу из БД формировать массив и отдавать на клиент.
 

fixxxer

К.О.
Партнер клуба
Если бы в PHP можно было описать интерфейс ассоциативного массива, как это делается в Typescript для plain JS objects - можно было бы и так, в Typescript я именно так и делаю. Вроде, в Hack что-то похожее есть (хотя, может, я путаю).

А сидеть ручками писать $model['foo'] и глазами, без какой-либо помощи IDE, высматривать опечатки - спасибо, нет.
 

Юрий Быков

Новичок
Согласен, PHP в этом плане пока туп. Очень не хватает структур и иммутабельности. Велком ФП.
 

Adelf

Administrator
Команда форума
Статической типизации не хватает. Но это будет уже не php.

А сидеть ручками писать $model['foo'] и глазами, без какой-либо помощи IDE, высматривать опечатки - спасибо, нет.
Написать как-то еще можно. Главная проблема, что потом не получится быстро рефакторить. нельзя Find usages эффективно юзать. А в случае ключа массива вообще невозможно :)
 

fixxxer

К.О.
Партнер клуба
Больше всего, на самом деле, не хватает дженериков. Классом или интерфейсом изображать старый добрый struct - это, в общем-то, один фиг. А вот вместо Collection<T> приходится всякую фигню городить.
 

fixxxer

К.О.
Партнер клуба
Да ничего там не хотят. RFC написал чувак, который вообще исходники PHP не открывал. Это очень масштабное изменение для PHP, затрагивающее весь zend engine, причем тут еще и надо учесть динамическую природу PHP со всеми его get_class и прочими new $className, которые должны как-то продолжать работать.
 

WMix

герр M:)ller
Партнер клуба
без обьекта не обойтись, на массиве (тем более усеченном) невозможно будет проиграть события.
 
Сверху