Самая удобная ORM

А мне нравится орм в кохане.... Там довольно таки просто и понятно реализовано.

1. Башка, в какой платформе?

Delphinum

Башка (19 Мая 2013 / 19:01)
Добрый день.
Начал реинженерить платформу, добрался до пакета ORM. Давайте подумаем вместе, какой интерфейс ORM был бы наиболее удобным в плане использования.
Сейчас работа примерно такая:
$dm = DataMapper::getInstance();
$o = new User();
$o->setLogin('Bashka');
$o->setPass('123');
$dm->insert($o); // Добавляем новый объект в базу
$o->setLogin('NewBashka');
$dm->update($o); // Обновляем данные об объекте
$id = $o->getOID();
$o = User::getProxy($id);
$dm->recover($o); // Получаем объект по его идентификатору

$o = $dm->recoverFinding($o, ['login' => 'NewBashka']); // Получаем объект по значению свойства
$dm->delete($o); // Удаляем объект из базы данных

Как бы вам хотелось производить эти операции?

Ужасно не красиво и не удобно. Лучше использовать ActiveRecord. И забрось ты уже эти велосипеды наконец, заюзай фв какой нибудь и не трать свое время на изобретение того что уже существует. Я уверен, что ты лучше не сделаешь сам ORM, которая будет лучше любой из сейчас популярных.

Что именно не удобно? Как было бы удобнее?

ActiveRecord это недоORM, мне хотелось бы полноценный ORM.

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

Сделаю или не сделаю, вот в чем вопрос )))

Добавлено через 07:37 сек.
А по теме, сделаю небольшой декоратор, для приверженцев управления данными через сущности ) думаю так будет и правильно и удобно

Сравни:

$dm = DataMapper::getInstance();
$o = new User();
$o->setLogin('Bashka');
$o->setPass('123');
$dm->insert($o);

и

$user = new User;

$user->login = 'Bashka';
$user->pass = '123';

$user->save();

Как по мне, второй вариант прекрасен. Здесь выполнена основная функция ORM - преобразование записи БД в объект. С этой записью теперь очень удобно работать в ООП коде.

Интересно, в чем же заключается это "недоORM"? В чем ее неполноценность?

$o->setLogin('Bashka');
$o->setPass('123');

Я надеюсь это динамические методы или их тоже самому надо всегда писать?

Нее, стоп, тут выбор такой не стоит, выбор между первым вариантом, и:
$user = DM::factory(new User);
$user->setLogin('Bashka');
$user->setPass('123');
$user->save();

Во втором варианте не преобразование записи в объект, там объект преобразовывает себя в запись БД. Вот это меня и смущает (если не использовать декоратор, да и там как то пахнет)

Все методы надо писать самому. Инкапсуляция.

Добавлено через 03:01 сек.
А еси получать объекты, то:
$r = DM::find('\PPHP\model\modules\Access\Role', 15);
вместо
$r = DM::recover(Role::getProxy(15));

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

Достаточно давно, Джоель Спольски написал отличный блог пост, о том – кто такие архитектурные астронавты.

Собственно, что за люди такие? Представте есть необходимость – закачивать файл на сайте. Просто файл – так как это видеохостинг – файл будет видео в различных форматах.

Как сделает обычный программист – закачка файла, определение по разширению, проверка валидности, и дальнейшие действия. Элементарно!

Что сделает архитектурный астронавт? В начале естественно он все это запроэктирует: визио диаграмма с тонной паттернов из всех возможных книг о паттернах программирования! Так же этот контрол будет неймоверно гибким, потому как будет состоять из взаимозаменямых модулей, который в любой момент можно переставить так, что контрол превращается в мп3 плеер. Ах да, ведь есть ещё мобильные системы – архитектру предусматривает что если пользователь зашел с моблильного телефона – конрол поддерживает возможность работы с мобильным телефоном 300т марок.

Это самый просто пример – аплоад контрол Представте чего может наворотить такой человек в сложной системе. Архитектурный астронавт – это не человек который решает проблему, а пытается решить шаблон проблемы. Если сравнить с доктором – это доктор которые не лечит лекарством, а ищет решение всех проблем.

Собственно, что удивительно, многие считают это профессионализмом – решение не одной проблемы, а целого вороха. И тут, как часто это бывает – проблема то и кроется. Время идет, а решения все нет, потому как обычное решение недостаточно гибкое, зависимое, и тому подобное. Когда приходит архитектура, программисты садятся и плачут. Откровенно.

Я не раз встречался с проектами, где реализация предложенной архитектуры – самый боттл нек. Не бизнесс логика, не рисования GUI, а создание такой структуры , которую описал архитект. Потому бойтесь их, и не пускайте в дом – очень малая вероятность того, что такие архитекты все же решат проблему.

http://maleevdimka.wordpress.com/2011/08/22/архитектурные-астронавты/

Тут основная соль именно в: удобство vs качество. Смотреть в сторону кохан это конечно хорошо, но нужно и в сторону гигантов поглядывать, типа openJPA, а так используется первый подход. Вот ломаю голову

Добавлено через 02:42 сек.
18. Ant0ha, ))) знаешь, в программировании есть такая догма - решать задачу нужно так, чтобы данное решение подходило для задачи, а не для конкретного ее проявления. Математика она такая )

Я горжусь тем, что подхожу к решению задач как Unixойд, а не как Windowsойд )

19. Башка, к решению задач ты подходишь как астронавт архитектуры и ОС тут не при чем. Я вот тоже уже несколько лет винду на дух не переношу и не использую ее.