Есть ли готовые компоненты для Symfony (но можно и без привязки к нему), способные делать то, что делает Doctrine через рефлексию?
Задача такова: есть некий набор данных, получаемых не из БД, на основании которого хочется уметь достаточно просто, например на основании xml-конфига (yaml, php - не особо важно), уметь создавать новые сущности неких классов уровня модели. Например, мы получили по API ответ от некоего сервиса, содержащий поля и их значения некоего объекта "Документ", и после на основании некоего конфига мы создаем новый инстанс класса Document, с заполненными свойствами нужными нам значениями. Свойства приватные. Понятно, что это делается на основании рефлексии, но хочется получить некую готовую разработку. Создавать через конструктор не вариант по своим причинам.
Есть что-то подобное, или придется все-таки писать самим?
Станислав, я предлагал вам создать некий класс - сущность (entity), как в Symfony..
но в отличии от сущности Symfony он не имел бы связи с БД, а использовался бы для временного хранения данных из ответа API..
В случае, если нужны приватные поля достаточно просто добавить геттеры и сеттеры)
Но, я так понимаю, это не совсем то что Вы искали, хотя если использовать это в куче с сериалайзерами/нормалайзерами, то вполне себе вариант..
Alex P., верно, искал не совсем то, мы работаем по DDD с БМПО, и геттеры-сеттеры не наш стиль :-) А так-то да, у нас именно что будут объекты, не связанные с БД сервиса, где они существуют, и мы будем заполнять их через рефлексию с сериализацией или типа того.
Именно как Доктрина через рекфлексию, то это ReflectionHydrator
Но в пакете есть и ряд других, не через рефлексию
Например свежая Cycle ORM юзает именно этот пакет
..................................
получили по API ответ от некоего сервиса, содержащий поля и их значения некоего объекта "Документ", и после на основании некоего конфига мы создаем новый инстанс класса Document, с заполненными свойствами нужными нам значениями. Свойства приватные
Создавать через конструктор не вариант по своим причинам.
А вот если прислушаться к вашей задаче, то что мешает создавать через фабричный метод (именованный конструктор)?
Конструктор плох тем, что может содержать какую-то внутреннюю логику, которая будет скрыта и с одной стороны может вносить какие-то неожиданные изменения, а с другой стороны должна дублироваться в случае использования сущностей в различных сервисах (проектах).
То есть, задача такая: есть некий (микро)сервис, который выступает в роли хранилища неких сущностей, документов, например. Он их должен создавать, он их должен отдавать на чтение, и тд. При этом другие сервисы тоже хотят работать с этой сущностью, но выступая в роли ее потребителя или инициатора создания, в части случаев. Из этого вытекает, что мы должны нарушать принцип DRY, если я верно его понимаю - тот же конструктор у нас должен с его логикой дублироваться на стороне обоих сервисов.
Соответственно, приемлемым решением видится создание объекта и заполнение его свойств на стороне ответственно службы, после чего передача данного объекта через сериализацию. Можно даже распространять конфиги таких сериализаций через некую общую точку ответственности, ну или как минимум один раз задать их в документации к ответственному сервису, после чего везде их использовать. Насколько я знаю, как-то подобным образом (через автоматизацию) такая задача решена в Авито, например.
