Меню
Что нового?

Read models naming

  • Автор темы Автор темы Adelf
  • Дата начала Дата начала
у вас разные контексты в разных пространствах имен?
 
grigori написал(а):
у вас разные контексты в разных пространствах имен?
Нажмите для раскрытия...
А я не про BC.
Они в разных слоях, обе модели друг про друга ничего не знают, и семантически и технически у них разные задачи. Даже слово «модель» к ним применима в разных смыслах.
В противном случае в API ты отдаёшь не «продукт», а «карточку продукта».
Когда удивлённый пользователь API спросит почему именно «карточка», то ты ему расскажешь, что это конфликтует с именем domain model.
Да и domain model со временем переименуешь, ведь на самом деле продукт на полках, а это — «КомпьютернаяМодельПродукта».
 
если на секунду вспомнить о graphql, то думается, что в php read-model должна быть основана на базе ассоциативного массива (к тому что клиент просил только определенный набор атрибутов). хотя возможно массив это конечное представление.
 
я так понимаю, что в этом случае (graphql) результирующая модель обрабатывается клиентом и от того что в пхп были бы generic-и или была бы возможность массивы типизировать, клиенту легче не становится.
задача только добыть и связать данные, все для связки (момент вычислений) по идеи и так храниться где-то в обьектах типа relation, а остальное как есть так и отдавать нужно. максимум что надо сделать, это проверить на разрешение запрошенные аттрибуты считывать.
 
А при чем тут клиент? Может, у меня тупой клиент, и все рендерится на сервере. Какое это отношение имеет к read model?
 
тупой клиент врятли на graphql общаться будет.
но если в твиг забабахать метод "graphql"
PHP: 
{% set user = graphql('{me{name}}') %}
<h1>{{user.name}}</h1>
то все опять на своем месте

fixxxer написал(а):
Какое это отношение имеет к read model?
Нажмите для раскрытия...
ну я так понимаю что graphql('{me{name}}') должно возвращать "read model"
 
Расскажите как будете использовать read-модель. Она действительна нужна в проекте? Может имеет смысл выдавать некий массив из обычной модели или сразу из БД формировать массив и отдавать на клиент.
 
Если бы в PHP можно было описать интерфейс ассоциативного массива, как это делается в Typescript для plain JS objects - можно было бы и так, в Typescript я именно так и делаю. Вроде, в Hack что-то похожее есть (хотя, может, я путаю).

А сидеть ручками писать $model['foo'] и глазами, без какой-либо помощи IDE, высматривать опечатки - спасибо, нет.
 
Согласен, PHP в этом плане пока туп. Очень не хватает структур и иммутабельности. Велком ФП.
 
Статической типизации не хватает. Но это будет уже не php.

fixxxer написал(а):
А сидеть ручками писать $model['foo'] и глазами, без какой-либо помощи IDE, высматривать опечатки - спасибо, нет.
Нажмите для раскрытия...
Написать как-то еще можно. Главная проблема, что потом не получится быстро рефакторить. нельзя Find usages эффективно юзать. А в случае ключа массива вообще невозможно :)
 
Больше всего, на самом деле, не хватает дженериков. Классом или интерфейсом изображать старый добрый struct - это, в общем-то, один фиг. А вот вместо Collection<T> приходится всякую фигню городить.
 
Да ничего там не хотят. RFC написал чувак, который вообще исходники PHP не открывал. Это очень масштабное изменение для PHP, затрагивающее весь zend engine, причем тут еще и надо учесть динамическую природу PHP со всеми его get_class и прочими new $className, которые должны как-то продолжать работать.
 
без обьекта не обойтись, на массиве (тем более усеченном) невозможно будет проиграть события.
 
Войдите или зарегистрируйтесь для ответа.
Сверху