Комментарии 17
Сделайте, пожалуйста, подсветку синтаксиса кода.
Ну и хотелось бы немного высказать своё ИМХО по вашей статье. Как мне кажется, подход ResultTransformer более применим в контексте паттерна Query Object, т. е. когда нам действительно не нужно получать из БД сущности, а нужны некие DTO. То что репозиторий возвращает что-то отличное от сущностей, как мне кажется не есть хорошо.
За статью спасибо.
Спасибо за комментарий)
Верно, возвращать из репозитория что-то кроме объекта сущности, это действительно не есть хорошо, и я об этом в статье тоже упомянул. Применение этого способа является исключением из правил, ведь Doctrine сама предоставляет нам эту возможность, почему бы ей не воспользоваться в редких сценариев, когда это действительно "к месту".
Тут скорее борьба автоматического и ручного маппинга. Для себя я решил так - если объекты небольшие или маппинг нужен в 1-2 других классов, то можно и руками, а если начинается чехорда, когда объекты крупные и их надо в кучу других классов маппить, то использую автомаппер, желательно, который использует кодогенерацию, чтобы не было ошибок в рантайме
Спасибо за статью, действительно полезный функционал
Вопрос будет не по теме: в чем смысл делать ридонли дто с приватными полями и геттерами? Коли он уже ридонли, так ведь проще сделать поля публичными?
Спасибо за комментарий.
Хороший вопрос. Если очень коротко, то вопрос безопасности и стандартов разработки, например соблюдения принципов ООП закрытость/открытость и единая ответственность и конечно же инкапсуляция.
честно говоря, не могу представить каким образом нарушается хотя бы один пункт из того что вы перечислили, кроме разве что внутренних стандартов разработки в компании
дто по определению выполняет одну функцию - трансфер данных; использование геттеров или прямого доступа на это не влияет
в дто обычно нет методов для работы с данными, поэтому инкапсуляции здесь в принципе не может быть - это по сути просто структура, если говорить процедурным языком; геттерами вы получается намеренно навязываете инкапсуляцию структуре
про безопасность тоже не совсем понял - public readonly поля чем-то менее безопасны, чем геттеры?
про нарушение открытости/закрытости хотел бы попросить пример конкретный пожалуй
это все только при условии, что вам вообще хочется дальше на эту тему дискутировать :D
Спасибо за конструктивный вопрос/ответ, а вот за минус не поблагодарю)
То есть по Вашему Расмус Лердорф настолько глуп что просто так для шутки ради придумал модификаторы доступа к параметрам класса/дто?
Если камень в мой огород исключительно приватныйх полей для дто, то верно, можно не указывать, как Вы указали это всего лишь трансфер между слоями приложения, не более. Лично я использую модификаторы уже по умолчанию, указываю их ради "приличного тона" разработки. Ну и конечно же мой шторм указывает на это.
Минус не мой🤔
Расмус не глуп, это очевидно, он реализовал аспекты ооп, просто он не мог учесть, что мир сдвинется в сторону от догматичного ооп к смешению парадигм. Собственно, к этому и пришли, когда ввели final readonly классы
Личные стандарты разработки это вполне себе повод делать геттеры, ничего против не имею, просто хотел выслушать мнение, спасибо)
Функционал действительно полезный, но у меня вопрос: что делать, если я хочу получить от IDE подсказки по полям DTO? У Вас в примерах возвращается только массив. При ручном маппинге это не проблема, так как поля для объекта мы задаём вручную, в как быть с автоматическим маппингом?
Использовать Doctrine на чтение очень плохая затея. Лучше уж использовать простой DBAL. Или ElaticSearch.
Почему нельзя было использовать Sumfony Normalizer? Это же проще.
Когда есть пользователь и заказ в больших системах, то такие запросы не получится сделать. Скорее это будут разные контексты и базы данных.
Вы в третьем комментарии сами ответила на первые два Ваших вопроса
Не "ответила", а "ответил")
Первый был не вопрос.
При разделении на микросервисы нужно делать не Database Join, а Application Join. И я не пытался в комментариях получить ответ. Я лишь с вами поделился первоочередными проблемами, которые уже говорят, что так делать нельзя. Разве что в очень простых сервисах.
Спасибо за статью, но в этой теме стоило бы побольше разобраться. Могу продолжить и ещё дополнить проблемами
1. На пустом месте создали новую инфраструктуру, которую нужно поддерживать, вместо того, чтобы взять готовый инструмент. Это я про маппинг на DTO) Тут либо использовать понятное проверенное решение, либо вообще отказаться от этой затеи.
2. В базе бывают не только скалярные типы, но и JSON, Datetime, Money, которые надо приводить в каким то данным. Json -> Array. DateTime -> DATE_ATOM и тд.
Извиняюсь, ли что-то не так написал. Хочу чтобы побольше разобрались в вопросе и сделали вторую часть)
Не "ответила", а "ответил")
Первый был не вопрос.
При разделении на микросервисы нужно делать не Database Join, а Application Join. И я не пытался в комментариях получить ответ. Я лишь с вами поделился первоочередными проблемами, которые уже говорят, что так делать нельзя. Разве что в очень простых сервисах.
Спасибо за статью, но в этой теме стоило бы побольше разобраться. Могу продолжить и ещё дополнить проблемами
1. На пустом месте создали новую инфраструктуру, которую нужно поддерживать, вместо того, чтобы взять готовый инструмент. Это я про маппинг на DTO) Тут либо использовать понятное проверенное решение, либо вообще отказаться от этой затеи.
2. В базе бывают не только скалярные типы, но и JSON, Datetime, Money, которые надо приводить в каким то данным. Json -> Array. DateTime -> DATE_ATOM и тд.
Извиняюсь, ли что-то не так написал. Хочу чтобы побольше разобрались в вопросе и сделали вторую часть)
Меня во второй раз не покидает чувство, что мы все-таки про разные задачи говорим.....
При чем тут микросервисы?
При чем тут типы данных, если мы их в нашей DTO указываем.
При чем тут ElaticSearch, о котором Вы в самом первом комментарии написали
Я как бы понимаю о чем идет речь, только я в статье не строил микросервис, а просто показал возможность доктрины из коробки, которая она умеет прекрасно решать одну узкую задачу.
ResultTransformer в Symfony проектах