-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
PDO fetchObject
- Автор темы hell0w0rd
- Дата начала
keltanas
marty cats
hell0w0rd
Ну чувак поумничать зашел, модные аббревиатуры пописать... Не понимаешь?
А чем тебя этот вариант не устраивает?
У тебя наверняка обработкой результата занимается какой-то метод. Наверняка есть конфиг, по которому ты составлял запрос.
Так возьми в этом методе, на основе конфига и напиши код, который распихает данные из запроса по объектам через setAttr(). Или создай __set(), который распихает данные по приватным свойствам.
Или я еще у себя в поделке делал в базовом классе доменного объекта защищенный массив $data, в котором хранятся значения полей объекта. А __set() и __get() распихивают/достают данные. В итоге даже получилось, что объект получается еще и сам себе прокси )) Правда сколько пользуюсь, до сих пор не могу понять, это костыль или фича )) (в Yii, вроде кстати, на подобие сделано)
Ну чувак поумничать зашел, модные аббревиатуры пописать... Не понимаешь?
А чем тебя этот вариант не устраивает?
У тебя наверняка обработкой результата занимается какой-то метод. Наверняка есть конфиг, по которому ты составлял запрос.
Так возьми в этом методе, на основе конфига и напиши код, который распихает данные из запроса по объектам через setAttr(). Или создай __set(), который распихает данные по приватным свойствам.
Или я еще у себя в поделке делал в базовом классе доменного объекта защищенный массив $data, в котором хранятся значения полей объекта. А __set() и __get() распихивают/достают данные. В итоге даже получилось, что объект получается еще и сам себе прокси )) Правда сколько пользуюсь, до сих пор не могу понять, это костыль или фича )) (в Yii, вроде кстати, на подобие сделано)
keltanas
marty cats
Ну это удобно, что мухи отдельно, котлеты отдельно. А в чем минусы?
Вурдалак
Продвинутый новичок
А тебя не коробит смешивать статические методы для вытягивания сущностей и методы самой сущности в одном классе? И какие минусы?
Это скорее котлета, но подаваемая по частям и ты сам должен смешать всё и бросить на сковороду, чтобы приготовить.
Мне нравится фреймворк laravel, у него мощная консоль, которая называется artisan (ремесленник-мастер). И вот по мере своей работы, я ощущаю себя именно ремесленником и мне нужен удобный инструмент, которым легко и без заморочек можно вбивать гвозди, а ORM вроде второй доктрины напоминают пресловутый микроскоп, который много чего умеет, но гвозди забивать неудобно. Мэпперы, репозитории, енти менеджеры - нафик это нужно, если объект живёт милисекунды, его не заберёт другой запрос, не нужно шарить между потоками и переживать и замарачиваться локами.
MiksIr
miksir@home:~$
Хм, а чем плох unit of work для умирающего языка? Мне так кажется точно такую же функцию выполняет, не больше и не меньше.
MiksIr
Он решает надуманную задачу, когда в пределах одного запроса я в разных кусках кода меняю объект. В ралаьности я либо так не делаю, либо тупо пробрасываю этот объект как зависимость. Другое дело что в параллельном потоке-запросе этот же объект могут менять и фактически identity map и unit of work должны шарить работу с объектом между потоками, а не в пределах одного реквеста.
Получается в простом варианте всё это оверхед, а когда реально нужно, то решение должно быть специфическим и использовать локи базы, шаренную память и семафоры.
Он решает надуманную задачу, когда в пределах одного запроса я в разных кусках кода меняю объект. В ралаьности я либо так не делаю, либо тупо пробрасываю этот объект как зависимость. Другое дело что в параллельном потоке-запросе этот же объект могут менять и фактически identity map и unit of work должны шарить работу с объектом между потоками, а не в пределах одного реквеста.
Получается в простом варианте всё это оверхед, а когда реально нужно, то решение должно быть специфическим и использовать локи базы, шаренную память и семафоры.
MiksIr
miksir@home:~$
Ну пробрасываешь как зависимость, а кто сохранять то его будет, в каком месте? И там и там?
И потом, как я понимаю, UoW еще попутно еще контролирует - что именно изменилось у объекта, облегчая апдейты.
Не говоря уж о транзакциях - это отличное место обернуть все с транзакцию.
И потом, как я понимаю, UoW еще попутно еще контролирует - что именно изменилось у объекта, облегчая апдейты.
Не говоря уж о транзакциях - это отличное место обернуть все с транзакцию.
keltanas
marty cats
AmdY
Ну ты либо имешь мегаОбъекты, которые могут и умеют все на свете, либо разделяешь обязанности по слоям.
Ну а уже на сколько детально разделять, дело каждого программиста.
Все давно согласились, что отделять Model, View и Controller удобно и теперь все так делают. Хотя это всего лишь вопрос удобства для программиста и можно сказать, что реализация MVC тоже оверхед в некоторых случаях.
Но, каждый из слоев можно расслоить еще, т.к. на каждом слое все еще выполняется достаточно много обязанностей.
А надо ли расслаивать дальше или нет, уже опять вопрос конкретного проекта и удобства для программиста.
Так что спор этот опять же сферический в вакууме. Как и универсальные системы вроде Propel и Doctrine которые здесь обычно хают. Они делаются, чтобы удовлетворять потребности большинства задач. Но, не решают конкретные задачи. Стоит ли винить эти библиотеки в универсальности? Я думаю, что нет, ибо они такими и задумывались. И возложенные на них функции выполняют хорошо.
Просто если нужен блэкджек и девочки, то выбор должен пасть на что-то другое.
Ну ты либо имешь мегаОбъекты, которые могут и умеют все на свете, либо разделяешь обязанности по слоям.
Ну а уже на сколько детально разделять, дело каждого программиста.
Все давно согласились, что отделять Model, View и Controller удобно и теперь все так делают. Хотя это всего лишь вопрос удобства для программиста и можно сказать, что реализация MVC тоже оверхед в некоторых случаях.
Но, каждый из слоев можно расслоить еще, т.к. на каждом слое все еще выполняется достаточно много обязанностей.
А надо ли расслаивать дальше или нет, уже опять вопрос конкретного проекта и удобства для программиста.
Так что спор этот опять же сферический в вакууме. Как и универсальные системы вроде Propel и Doctrine которые здесь обычно хают. Они делаются, чтобы удовлетворять потребности большинства задач. Но, не решают конкретные задачи. Стоит ли винить эти библиотеки в универсальности? Я думаю, что нет, ибо они такими и задумывались. И возложенные на них функции выполняют хорошо.
Просто если нужен блэкджек и девочки, то выбор должен пасть на что-то другое.
hell0w0rd
Продвинутый новичок
Ну то что Amdy пишет имеет приличный смысл. Ибо я не знаю что за задача, в которой два раза приходится работать с одной и той же entity при обработке одного запроса.
Однако AR мне не нравится ни в каком виде. UoW удобно использовать, чтобы пропихнуть в базу все в одной транзакции. Ну у доктрины как-то все слишком запутано, фактически 3 центральных класса имеют ссылки друг на друга, то есть все 3 класса делают не пойми что.
Однако AR мне не нравится ни в каком виде. UoW удобно использовать, чтобы пропихнуть в базу все в одной транзакции. Ну у доктрины как-то все слишком запутано, фактически 3 центральных класса имеют ссылки друг на друга, то есть все 3 класса делают не пойми что.
keltanas
marty cats
hell0w0rd
Может быть задача, при которой вызывается событие, в которое передается какой-то этот объект. И код, который вызывает событие не знает, изменился ли объект после обработки события, ни обработчик не знает, стоит ли сохранять объект, т.к. дальше он может быть передан в следующий обработчик, который снова может что-то поменять.
Получается либо ситуация неопределенности, при которой не понятно, что объект был объект изменен и его надо сохранить, либо оверхед, когда объект сохраняется при каждом изменении (или сохранять, даже если ничего не поменялось).
В корпоративной системе таких приколов на каждом шагу. В соц. сетях роль UoW выполняют внешние сервисы, реализуемые через очереди и разгребающие их кроны. На обычном сайте, где мы в основном занимаемся чтением информации, а правкой занимается один админ UoW действительно бесполезен.
Вот типичная ситуация из жизни: Когда идентифицированный пользователь открывает ЛК, то сначала проверяется его идентификация и обновляется поле lastVisitedAt.
И в этой же сессии происходит обработка формы, где данный пользователь меняет свой номер телефона.
В известном фреймворке нам придется выполнить 2 запроса сначала на выборку, а потом на апдейт одной и той же записи таблицы. Вот вам и оверхед для БД.
При том, что оверхед, связанный с использованием UoW и IM легко масштабируемый простым клонированием app-сервера, что не скажешь о БД.
Может быть задача, при которой вызывается событие, в которое передается какой-то этот объект. И код, который вызывает событие не знает, изменился ли объект после обработки события, ни обработчик не знает, стоит ли сохранять объект, т.к. дальше он может быть передан в следующий обработчик, который снова может что-то поменять.
Получается либо ситуация неопределенности, при которой не понятно, что объект был объект изменен и его надо сохранить, либо оверхед, когда объект сохраняется при каждом изменении (или сохранять, даже если ничего не поменялось).
В корпоративной системе таких приколов на каждом шагу. В соц. сетях роль UoW выполняют внешние сервисы, реализуемые через очереди и разгребающие их кроны. На обычном сайте, где мы в основном занимаемся чтением информации, а правкой занимается один админ UoW действительно бесполезен.
Вот типичная ситуация из жизни: Когда идентифицированный пользователь открывает ЛК, то сначала проверяется его идентификация и обновляется поле lastVisitedAt.
И в этой же сессии происходит обработка формы, где данный пользователь меняет свой номер телефона.
В известном фреймворке нам придется выполнить 2 запроса сначала на выборку, а потом на апдейт одной и той же записи таблицы. Вот вам и оверхед для БД.
При том, что оверхед, связанный с использованием UoW и IM легко масштабируемый простым клонированием app-сервера, что не скажешь о БД.