Read models naming

[grigori]

у вас разные контексты в разных пространствах имен?

 

[grigori]

коллекция этих read models идет во вьюху

объект для передачи между слоями - это определение DTO

 

[Вурдалак]

у вас разные контексты в разных пространствах имен?

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

 

[fixxxer]

объект для передачи между слоями - это определение DTO

Да, можно сказать, что Read Model - это частный случай DTO. А в чем проблема с этим?

 

[WMix]

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

 

[fixxxer]

в php read-model должна быть основана на базе ассоциативного массива

Если бы в php можно было их типизировать, как в typescript, и если бы в php были generic-и... А без этого слишком это все хрупко.

 

[WMix]

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

 

[fixxxer]

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

 

[WMix]

тупой клиент врятли на graphql общаться будет.
но если в твиг забабахать метод "graphql"

{% set user = graphql('{me{name}}') %}
<h1>{{user.name}}</h1>

то все опять на своем месте

Какое это отношение имеет к read model?

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

 

[Юрий Быков]

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

 

[AnrDaemon]

выдавать некий массив из обычной модели

Это и будет read model…

 

[fixxxer]

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

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

 

[Юрий Быков]

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

 

[Юрий Быков]

Это и будет read model…

В моём понимании модель это объект, а не массив, поэтому это не одно и тоже.

 

[Adelf]

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

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

Написать как-то еще можно. Главная проблема, что потом не получится быстро рефакторить. нельзя Find usages эффективно юзать. А в случае ключа массива вообще невозможно

 

[fixxxer]

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

 

[Юрий Быков]

Их хотят добавить в будущих версиях. В хаке уже есть.

 

[fixxxer]

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

 

[AnrDaemon]

В моём понимании модель это объект, а не массив, поэтому это не одно и тоже.

Принцип "есть два мнения - моё и неправильное" здесь не работает.

 

[WMix]

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