Обсуждение различных реализаций ORM

[zerkms]

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

ну это уже особенности сабжа - непосредственно с sql работать не приходится - всё спрятано за орм
[off]
и не надо мне доказывать, что ORM отстой и не гибко - мне лучше знать, как мне удобнее работать
[/off]

 

[dark-demon]

> и не надо мне доказывать, что ORM отстой и не гибко

не вижу смысла доказывать очевидные вещи.


> мне лучше знать, как мне удобнее работать

ты никогда не задумывался, что написанную тобой программу придётся поддерживать кому-то другому?

 

[zerkms]

не вижу смысла доказывать очевидные вещи.

абсолютно не очевидно. во флеймовых топиках ни разу не было однозначной победы ни той, ни другой стороны

ты никогда не задумывался, что написанную тобой программу придётся поддерживать кому-то другому?

моя хата с краю
ps: имхо, всё таки поддержка моего кода, с использованием ОРМ - будет куда более простой, чем поддержка кода без орм :-Р

 

[dark-demon]

ну, возьмём пример с прошлой страницы...

есть таблица со статьями:
numb - номер записи
id - идентификатор статьи
title - название
descr - описание
content - содержимое
time - время коммита

id у записей может совпадать, что соответствует разным версиям одной статьи.

возможные операции:
* вывести список статей
* добавить ревизию
* откатить до определённой версии
* вывести все ревизии одной статьи

как это разрулить с помощью ORM?

 

[Wicked]

Пример из доктрины:
http://www.phpdoctrine.org/documentation/manual/1_0?one-page#plugins:auditlog-and-versioning

объявляем articles как versionable, и далее как-то так (сам пока что versionable не использовал, так что могу немного ошибаться):

* вывести список статей

dql: "select * from articles"
либо
$conn->getTable("articles")->findAll();

* добавить ревизию

$article->title = "bla-bla-bla";
$article->save();

* откатить до определённой версии

$article->revert($rev)

* вывести все ревизии одной статьи

dql: "select * from articles_version where id = ?"
либо
$conn->getTable("articles_versions")->find($id);

 

[atv]

dark-demon, я уже приводил аргументы в пользу ORM, на которые НИКТО не смог привести контр-аргументы:
1) ORM предназначена для устранения ДУБЛИРОВАНИЯ КОДА при работе с БД.
2) ORM не предназначена для отображения СВОДНЫХ ТАБЛИЦ на странице, для этого предназначен паттерн DataSet.

 

[dark-demon]

> select * from articles

для каждой статьи надо получить последнюю ревизию данных, а не просто список идентификаторов. не в цикле же их получать?

> select * from articles_version

все ревизии всех статей? o_0


atv, мне без разницы что для чего предназначего. как решает поставленную задачу этот твой DataSet?

 

[atv]

мне без разницы что для чего предназначего

Ты подумал что сказал? Это ответ мартышки из басни, которая не поняла предназначения очков.

как решает поставленную задачу этот твой DataSet

Во-первых, он не мой, а во вторых, для решения задачи понадобиться и ORM и DataSet. Для операций вставки, обновления и удаления используется ORM, для построения сводных таблиц - DataSet.

Если "* вывести список статей" означает генерацию HTML таблицы для отображения пользователю, тогда пользуем DataSet. Если же, список статей нужен для какой-либо обработки в приложении - ползуем ORM.

 

[dark-demon]

> Если же, список статей нужен для какой-либо обработки в приложении - ползуем ORM.

как?

 

[atv]

Некоторые ORM позволяют получать коллекцию объектов по raw запросу, при условии, что результат вернёт все необходимые поля.

 

[dark-demon]

и тут мы приходим к тому, с чего собственно спор и начался: "это уже особенности сабжа - непосредственно с sql работать не приходится - всё спрятано за орм"

 

[atv]

> и не надо мне доказывать, что ORM отстой и не гибко

не вижу смысла доказывать очевидные вещи.

Это тезис относился к ORM вообще, а не конкретной реализации.

"непосредственно с sql работать не приходится" - это тоже не верно, ORM не покрывает всех нужд работы с данными, поэтому приходиться использовать несколько подходов, каждый в своей области применения, как то DataSet-ы и SqlBuilder-ы для ручного составления запросов.

Кстати, именно поэтому, я поместил в свой SqlBuilder возможность маппинга полей таблицы. Теперь и ORM и DataSet используют единый маппинг через SqlBuilder.

 

[dark-demon]

+1

 

[StUV]

раз такое дело - тоже "попиаримся"

классный орм

$qry = 'SELECT `a`.`name`, `a`.`id` FROM `sys_access_registry` `r`
INNER JOIN `sys_classes_sections` `cs` ON `cs`.`id` = `r`.`class_section_id`
INNER JOIN `sys_classes_actions` `ca` ON `ca`.`class_id` = `cs`.`class_id`
INNER JOIN `sys_actions` `a` ON `a`.`id` = `ca`.`action_id`
WHERE `r`.`obj_id` = ' . $this->obj_id;

 

[zerkms]

StUV
и?
генератор запросов/орм я юзаю исключительно там, где оно нужно... смысл втыкать его везде то?

 

[StUV]

zerkms
так, взгляд со стороны... свои "холивары" я уже отвоевал

 

[zerkms]

StUV
тут никто и не воюет так, кидаем камни в огороды друг друга )))))