Как использовать Entity, Mapper, Service и Hydrator в ZF2

Я делаю приложение ZF2. Я использую сущности, сопоставители и службы (например, UserEntity, UserMapper, UserService) для управления объектами/моделями. Свойства в сущностях имеют CamalCased (например, FirstName, LastName), в то время как в базе данных поля используют подчеркивание (first_name, last_name). Я планирую использовать гидратор для сопоставления свойств и полей базы данных при извлечении или сохранении. Объект службы (UserService) будет использоваться для связи с преобразователем для извлечения и сохранения моделей данных с помощью преобразователя. Гидратор преобразует результат картографа и преобразует их в правильные объекты.

Меня смущает то, что когда службе (UserService) необходимо предоставить некоторые критерии - например, чтобы найти всех пользователей с определенной «фамилией», будет ли служба использовать имена полей базы данных (last_name) или имя свойства объекта (LastName )?

Если имя поля db используется в службе, то любое изменение в структуре db потребует от меня также обновления службы, что полностью не позволяет использовать весь подход.


person J Morgan    schedule 26.08.2013    source источник
comment
Есть ли какой-то конкретный гидратор, который вы имели в виду? Некоторым потребуются имена столбцов базы данных, а некоторым нет. Я знаю, что использовать Doctrine 2 с ZF2 достаточно просто. В Doctrine 2 для запросов используются только имена свойств.   -  person Cerad    schedule 26.08.2013
comment
Я буду использовать гидратор ClassMethods. Насколько я понимаю, гидратор может извлекать/увлажнять все свойства, и мы не можем использовать его для гидратации/извлечения только нескольких свойств.   -  person J Morgan    schedule 28.08.2013


Ответы (1)


Если вы посмотрите на метод ClassMethods:hydrate (https://github.com/zendframework/zf2/blob/master/library/Zend/Stdlib/Hydrator/ClassMethods.php), вы увидите, что он просто копирует свойства из одного объекта в другой. У вас есть возможность преобразовать имена свойств в/из camelCase, но это все.

Если вы измените имя столбца в своей базе данных, вам нужно будет изменить соответствующее имя свойства в вашем объекте. Наоборот. Что я считаю сутью вашего вопроса?

Если вы хотите, чтобы имена столбцов таблицы не зависели от имен ваших методов, вам нужно что-то, что позволит вам где-то определить фактическую таблицу сопоставления. Измените имя столбца или метода, и вам нужно будет только обновить таблицу сопоставления конфигурации.

Не эксперт по ZF2, поэтому могу ошибаться, но похоже, что ни один из поставляемых гидраторов не поддерживает это.

Я знаю, что Doctrine 2 поддерживает это.

person Cerad    schedule 28.08.2013
comment
насколько я понимаю, подход гидратора преобразует полное свойство в db_fields и наоборот. Он обеспечивает сопоставление, и я хочу использовать его сопоставление. поэтому, если в будущем произойдут какие-либо изменения в БД, мне нужно будет только обновить сопоставление. Я хочу использовать одно и то же сопоставление для преобразования только определенных/предоставленных свойств/полей, когда это необходимо. - person J Morgan; 28.08.2013
comment
Неа. Посмотрите на исходный код. Нет картографической информации. Просто использует любые имена столбцов таблицы и при необходимости преобразует их в верблюжий регистр. Вероятно, вы могли бы создать свой собственный гидратор, но ваши запросы все равно будут привязаны к конкретным именам столбцов. Попытайся. - person Cerad; 29.08.2013
comment
Я проверил код и согласен с вами в том, что он в основном изменяет/сопоставляет «подчеркнутые» поля с camelCase. Но мы также можем расширить его и выполнять различные действия для любого заданного ключа. например если объект имеет имя свойства «id», а база данных имеет имя поля «user_id», мы можем расширить класс, а в извлечении/гидрате мы добавим функциональность, чтобы он преобразовывался между объектом и массивом в соответствии с нашими потребностями. Теперь я хочу, чтобы я использовал существующие функции гидратора, чтобы обеспечить преобразование для определенных полей, а не для всей строки/объекта. - person J Morgan; 29.08.2013
comment
Конечно, вы можете сделать гидратор на заказ. Но поможет ли это сохранить независимость вашей базы данных критериев? - person Cerad; 29.08.2013
comment
это то, что на самом деле я ищу, чтобы мои службы, сущности и т. д. не знали, как хранятся данные. Поэтому, если сервису необходимо предоставить некоторые критерии, касающиеся какого-либо конкретного свойства, он будет запрашивать преобразователь и, возможно, напрямую использовать гидратор, или преобразовывать гидрататор и преобразовывать критерии в соответствии со структурой/полями БД. - person J Morgan; 29.08.2013
comment
Итак, ваш вопрос действительно о UserService? Планируете ли вы использовать класс ZF2 для этого? Если да, то какой? - person Cerad; 29.08.2013