Самая удобная ORM
1. Артур (19.05.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); // Удаляем объект из базы данных
Как бы вам хотелось производить эти операции?
2. JustZero (19.05.2013 / 19:16)
<?php $o = DataMapper::getInstance(new User); $o->login = 'Bashka'; $o->passwd = md5(1234); $o->save();
как по мне, то удобно
Добавлено через 01:04 сек.
вообще в kohanaframework удобно все сделано)
3. Артур (19.05.2013 / 19:22)
Мне не понравился kohana, изучал. В частности не понравилось следующее:
1. Для любого использования ORM нужно два действия: 1 - оборачивание объекта; 2 - само действие;
2. Я так и не понял зачем добавляется какая либо логика к самому объекту? Почему бы не оставить логику в слое ORM?
3. В чем то согласен что save, delete и insert закрепленные на объектах это удобно, но лично меня это путает
4. orel (19.05.2013 / 19:26)
Как в фреймворках типа
$model = New User; $model->name_user = 'MyName'; $model->pass_user = '123'; $model->save(); //Или $model->insert(); $model->get_array();
5. Артур (19.05.2013 / 19:27)
Уже двое настаивают на закреплении save, insert и delete на объектах. Подождем еще
6. JustZero (19.05.2013 / 19:31)
не ну setLogin(), setPasswd() такие ф-ции писать нужно самому будет походу в модели. зачем делать в ручную, если автоматом можно сделать)
7. Артур (19.05.2013 / 20:01)
Сеттеры? В них разве есть логика?
8. orel (19.05.2013 / 21:10)
1. Башка, а ты выложил выложишь свое изобретение?
9. Изнаур (19.05.2013 / 21:17)
8. Орёл, http://visavi.net/forum/topic.php?tid=33393& думаю под делфиниум и пишется
P.S согласен с постами 2 и 4
10. Артур (19.05.2013 / 21:24)
Да, просто немного изменений в этой платформе
11. WapMarkiz (19.05.2013 / 21:27)
А мне нравится орм в кохане.... Там довольно таки просто и понятно реализовано.
12. orel (19.05.2013 / 21:42)
1. Башка, в какой платформе?
13. Артур (19.05.2013 / 22:17)
Delphinum
14. Ant0ha (19.05.2013 / 22:18)
Башка (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, которая будет лучше любой из сейчас популярных.
15. Артур (19.05.2013 / 22:25)
Что именно не удобно? Как было бы удобнее?
ActiveRecord это недоORM, мне хотелось бы полноценный ORM.
Не нашел подходящих для меня библиотек, с другой стороны не хочу делать мой проект зависимым от сторонних разработок, которые завтра могут стать платными или умереть.
Сделаю или не сделаю, вот в чем вопрос )))
Добавлено через 07:37 сек.
А по теме, сделаю небольшой декоратор, для приверженцев управления данными через сущности ) думаю так будет и правильно и удобно
16. Ant0ha (19.05.2013 / 22:33)
Сравни:
$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');
Я надеюсь это динамические методы или их тоже самому надо всегда писать?
17. Артур (19.05.2013 / 22:38)
Нее, стоп, тут выбор такой не стоит, выбор между первым вариантом, и:
$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));
18. Ant0ha (19.05.2013 / 22:43)
Не в обиду, но ты для меня типичный астронавт архитектуры. Не хочу тебя обидеть и не посчитай это переходом на личности. Просто может поможет посмотреть на это со стороны.
Достаточно давно, Джоель Спольски написал отличный блог пост, о том – кто такие архитектурные астронавты.
Собственно, что за люди такие? Представте есть необходимость – закачивать файл на сайте. Просто файл – так как это видеохостинг – файл будет видео в различных форматах.
Как сделает обычный программист – закачка файла, определение по разширению, проверка валидности, и дальнейшие действия. Элементарно!
Что сделает архитектурный астронавт? В начале естественно он все это запроэктирует: визио диаграмма с тонной паттернов из всех возможных книг о паттернах программирования! Так же этот контрол будет неймоверно гибким, потому как будет состоять из взаимозаменямых модулей, который в любой момент можно переставить так, что контрол превращается в мп3 плеер. Ах да, ведь есть ещё мобильные системы – архитектру предусматривает что если пользователь зашел с моблильного телефона – конрол поддерживает возможность работы с мобильным телефоном 300т марок.
Это самый просто пример – аплоад контролПредставте чего может наворотить такой человек в сложной системе. Архитектурный астронавт – это не человек который решает проблему, а пытается решить шаблон проблемы. Если сравнить с доктором – это доктор которые не лечит лекарством, а ищет решение всех проблем.
Собственно, что удивительно, многие считают это профессионализмом – решение не одной проблемы, а целого вороха. И тут, как часто это бывает – проблема то и кроется. Время идет, а решения все нет, потому как обычное решение недостаточно гибкое, зависимое, и тому подобное. Когда приходит архитектура, программисты садятся и плачут. Откровенно.
Я не раз встречался с проектами, где реализация предложенной архитектуры – самый боттл нек. Не бизнесс логика, не рисования GUI, а создание такой структуры , которую описал архитект. Потому бойтесь их, и не пускайте в дом – очень малая вероятность того, что такие архитекты все же решат проблему.
http://maleevdimka.wordpress.com/2011/08/22/архитектурные-астронавты/
19. Артур (19.05.2013 / 22:43)
Тут основная соль именно в: удобство vs качество. Смотреть в сторону кохан это конечно хорошо, но нужно и в сторону гигантов поглядывать, типа openJPA, а так используется первый подход. Вот ломаю голову
Добавлено через 02:42 сек.
18. Ant0ha, ))) знаешь, в программировании есть такая догма - решать задачу нужно так, чтобы данное решение подходило для задачи, а не для конкретного ее проявления. Математика она такая )
Я горжусь тем, что подхожу к решению задач как Unixойд, а не как Windowsойд )
20. Ant0ha (19.05.2013 / 22:51)
19. Башка, к решению задач ты подходишь как астронавт архитектуры и ОС тут не при чем. Я вот тоже уже несколько лет винду на дух не переношу и не использую ее.
21. Артур (19.05.2013 / 22:52)
Да я не про ОС, я про философию ) Ладно, забыли и вернулись к теме. Думаю сделаю смешанную архитектуру, не стану смешивать логику интерпретации объекта в SQL в сам объект, вынесу на сторону и добавлю декоратор
22. Ant0ha (19.05.2013 / 22:52)
Ладно, дело твое, не буду мешать твоим поискам архитектуры "самой удобной ORM"
Добавлено через 01:09 сек.
Расскажешь потом, лет так через 10 что получилось, если до этого времени что то получится)
23. Артур (19.05.2013 / 22:54)
Ты мне ни сколько не мешаешь )
24. Ant0ha (19.05.2013 / 22:58)
http://visavi.net/blog/blog.php?act=view&id=275&
http://visavi.net/blog/blog.php?act=comments&id=275&
и это было почти 2 года назад...
25. Артур (19.05.2013 / 22:59)
Еще мне очень бы хотелось услышать какое нибудь сравнение реализаций в различных фреймворках. Складывается ощущение что отписались пользователи, которые изучили только кохану (
26. Ant0ha (19.05.2013 / 23:00)
Башка (19 Мая 2013 / 22:59)
Еще мне очень бы хотелось услышать какое нибудь сравнение реализаций в различных фреймворках. Складывается ощущение что отписались пользователи, которые изучили только кохану (
да суть таже, ActiveRecord в тренде)
это та, которая недоORM)
27. Артур (19.05.2013 / 23:00)
Да. Это было замечательное время, столько неизвестного было впереди. Ни чуть не жалею потерянного времени. Кстати, тогда я использовал именно тот подход, что предлагают пользователи и решил от него отказаться, держит только удобство (он реально удобен)
28. Ant0ha (19.05.2013 / 23:01)
deleted
29. Артур (19.05.2013 / 23:02)
26. Нии! Не говори мне об ActiveRecord, это совершенно не та реализация! Там нет абстрагирования от структуры БД, а я не хочу задумываться об именах полей и таблицах
30. Ant0ha (19.05.2013 / 23:09)
Башка (19 Мая 2013 / 23:02)
26. Нии! Не говори мне об ActiveRecord, это совершенно не та реализация! Там нет абстрагирования от структуры БД, а я не хочу задумываться об именах полей и таблицах
Прошу прощения, все известные мне фреймворки используют ActiveRecord: kohana, yii, symfony, laravel, fuelphp.
31. Артур (19.05.2013 / 23:10)
Я хочу отделить объекты от базы данных. Не хочу создавать объекты только для управления базой данных.
32. Ant0ha (19.05.2013 / 23:12)
А почему это? Наверно для того чтобы создать гибкую систему для решения всех проблем? Ведь нельзя на Doctrine, например, написать расширяемый сайт.
33. Артур (19.05.2013 / 23:12)
Вот в этом и проблема, ты знаешь реализацию только через AR, следовательно он удобный, хороший, и наконец просто красавица (
Добавлено через 01:15 сек.
Дададад. Гибкость для платформы это наиболее важное качество. Да и для любой библиотеки в частности.
Написать можно, а как сопровождать?
34. Ant0ha (19.05.2013 / 23:15)
Вот именно, сайты на symfony 2 (используется AR Doctrine), совершенно не поддаются сопровождению. На кохане и уии та же фигня.
35. Артур (19.05.2013 / 23:16)
Почему же совершенно?
Кстати, как Doctrine справляется с наследованием классов?
36. Ant0ha (19.05.2013 / 23:28)
Башка (19 Мая 2013 / 23:16)
Почему же совершенно?
Кстати, как Doctrine справляется с наследованием классов?
Я не работал с ней, просто привел как пример часто используемой отдельной библиотеки ORM. Но классы AR (модели) наследуются как и обычные классы. А в чем проблема должна быть?
37. Артур (19.05.2013 / 23:30)
Интересно как реализовано. Приходится ли что то дописывать?
38. Ant0ha (19.05.2013 / 23:33)
Башка (19 Мая 2013 / 23:30)
Интересно как реализовано. Приходится ли что то дописывать?
я очень много работал с моделями в кохане. у меня есть проект даже с около 130 таблиц (это примерно столько же моделей за вычетом through таблиц для связей many to many). я расширял базовый ORM, но дописывал в него совсем не много своего кода. мелочи.
ну, и для каждой модели тоже писал свои методы, нужные только для нее. всё прекрасно. с расширяемостью нет проблем.
Добавлено через 03:18 сек.
Башка (19 Мая 2013 / 23:30)
Интересно как реализовано. Приходится ли что то дописывать?
вот просто возьми и создай простенький проект на фреймоврке, используй встроенную орм и после нее ты врядли захочешь иметь дело с велосипедами.
39. Артур (19.05.2013 / 23:37)
Я на работе так и делаю ;) Только пишу как правило на Java с использованием OpenJPA или на C++ с использованием кьюта
Добавлено через 02:03 сек.
У меня проект с 143 таблицами )))
Вообще есть одна важная вещь, которую по сути AR делать не может. Как правило при расширении проекта сторонней группой программистов приходится расширять сущности через наследование, в AR сталкивася с тем, что код в объектных-записях либо очень раздут либо вообще не позволяет без переписывания существующих табилц и кода что то расширять
40. Ant0ha (19.05.2013 / 23:42)
Башка (19 Мая 2013 / 23:37)
У меня проект с 143 таблицами )))
пруф линк можно? отмазки типа "он сейчас недоступен", "это секрет" не принимаются.
41. Артур (19.05.2013 / 23:43)
del
Добавлено через 00:54 сек.
Даже 145
Добавлено через 01:34 сек.
Через пару минут удалю ссылку ) "секрет"
42. Ant0ha (19.05.2013 / 23:45)
ок, проехали
Добавлено через 02:16 сек.
Башка (19 Мая 2013 / 23:37)
Вообще есть одна важная вещь, которую по сути AR делать не может. Как правило при расширении проекта сторонней группой программистов приходится расширять сущности через наследование, в AR сталкивася с тем, что код в объектных-записях либо очень раздут либо вообще не позволяет без переписывания существующих табилц и кода что то расширять
многое не понял, но как с этими же проблемами помогает справиться датамаппер?
Добавлено через 05:01 сек.
хотя, у меня проблем не возникало, всё ок. я не знаю как вы там работаете.
43. Артур (19.05.2013 / 23:53)
Вот, глянь тесты, думаю будет понятно
Добавлено через 02:24 сек.
Вот к примеру задача. У тебя есть класс User который имеет свойства login и pass. Для него есть таблица в БД USERS[LOGIN, PASS]. Тебе нужно добавить в класс дополнительное свойство IP. Как ты это сделаешь? При это добавлять прямо в класс нельзя, нужно наследовать
44. Ant0ha (19.05.2013 / 23:59)
Вот к примеру задача. У тебя есть класс User который имеет свойства login и pass. Для него есть таблица в БД USERS[LOGIN, PASS]. Тебе нужно добавить в класс дополнительное свойство IP. Как ты это сделаешь? При это добавлять прямо в класс нельзя, нужно наследовать
зачем? я создаю миграцию с добавлением поля ip в таблицу и работаю с этим свойством - всё.
Добавлено через 01:53 сек.
orm сама добавит в свойства на основе структуры таблицы. а она это умеет) и не только это)
Добавлено через 03:38 сек.
другой человек может выкачать с помощью git эту миграцию, выполнить ее и так же работать с этим новым свойством. никакой магии. ничего сложного нет.
Добавлено через 06:43 сек.
офф, лучше бы я в это время лингво львенка накормил, чем доказывал тебе простые вещи)
45. Артур (20.05.2013 / 00:14)
Еще один запрос для получения информации о структуре таблицы?
Вот об этом я и говорю, мы работает иначе, мы создаем наследника, добавляем ему все что надо и работаем с ним как с обычным объектом. Как бы правильно выразиться - мы работаем с объектами классическим образом, а вы работаете с базой данных через объекты. Вот это мне не нравиться
Добавлено через 00:14 сек.
У меня сущности это котлеты, а база это мухи
46. Ant0ha (20.05.2013 / 00:21)
> Еще один запрос для получения информации о структуре таблицы?
запрос можно кэшировать либо добавлять поле явно в свойства
> У меня сущности это котлеты, а база это мухи
вот расскажи мне, нафига это надо? если твоя цель как раз таки в объединении записей бд с этими сущностями?
47. Артур (20.05.2013 / 00:23)
Для того чтобы иметь высокое зацепление и низкое связывание - GRASP
Цель решить задачу так, чтобы потом можно было изменять реализацию без переписывания всей библиотеки
48. Ant0ha (20.05.2013 / 00:24)
Вот, типичное мышление астронавта архитектуры. Сори, нам просто не понять друг друга.
Добавлено через 03:09 сек.
Я легко расширяю проект и не переписываю ORM. Цель достигнута изначально и не мной. КПД тут повыше будет.
49. Ant0ha (20.05.2013 / 00:36)
Я, как бы, делегирую разработку моста между относительно низкоуровневым программированием и программированием на более высоком уровне (разработку фреймворка) другим людям. А сам занимаюсь тем, чем мне нужно заниматься - разработкой конечного продукта. Тут как бы разделение труда идет.
50. Артур (20.05.2013 / 00:42)
Дело в том, что я не прикладной программист, я ведущий разработчик и координатор проекта, тут нельзя по принципу - главное чтоб работало - нужно все тщательно придумывать, чтоб эффективно использовать время
51. Ant0ha (20.05.2013 / 00:45)
А какой эффективности использования времени тут речь? Ты что?!) И повернулся же язык такое сказать.
52. Артур (20.05.2013 / 00:46)
А с разделением труда согласен, только вот использую YUI3 и все удивляюсь, чего она на опере так виснет, а моя библиотека на всех арбузах работает одинаково. Хотя йуи посерьезнее любых кохан будет, но вот приходится мириться ибо разделение труда
Добавлено через 01:39 сек.
Поверь мне, клиентов наши сроки устраивают вполне + качество не страдает и всегда готовы к дополнениям
53. Ant0ha (20.05.2013 / 00:50)
Я так понимаю, ты хочешь сказать, что проекты на фреймворках (зенд, кохана, уии, симфони и тп) уступают по качеству и времени разработки проектов на твоём дельфинуме (если не ошибаюсь, его так ты назвал)?
54. Артур (20.05.2013 / 00:53)
Где ты такое умудрился вычитать? Куда мне против гениев AR )
Добавлено через 01:14 сек.
Кстати YUI3 это не yii ;) а то часто путают
55. Ant0ha (20.05.2013 / 00:58)
Башка (20 Мая 2013 / 00:42)
Дело в том, что я не прикладной программист, я ведущий разработчик и координатор проекта, тут нельзя по принципу - главное чтоб работало - нужно все тщательно придумывать, чтоб эффективно использовать время
Хотя бы в этом сообщении, да и во многих других. Суть такая - готовые решения - г*вно. Ты знаешь как сделать лучше. Ты же ведь создаешь "самую лучшую ORM". Не так разве?
Мы все пользователи фреймоврков не ведущие программисты и нам до тебя далеко. Выходит так.
56. Артур (20.05.2013 / 01:03)
Ты сейчас подводишь мои слова под твои мысли )
Пользоваться готовыми решениями отлично, только я не смог подобрать для себя ни одного, о чем уже писал ранее, а сейчас спрашиваю как лучше реализовать по мнен ию других пользователей. Вот такие слова )
57. Ant0ha (20.05.2013 / 01:20)
А по-моему, у тебя просто не хватило желания понять как правильно работать с готовыми решениями вот и всё. Ты завуалировал это тем, что тебе ничто не подходит. И вместо того чтобы разобраться фреймворками (которые, кстати, подходят очень многим программистам), ты решил написать что-то свое. При этом твое раздутое эго "ведущего программиста" говорит тебе - я должен помочь миру и написать что то великое. То, что будет лучше всех (название топика это подтверждает).
Ты просто программист-юниор, не желающий признать свою недалекость. Вот и всё. Многие через это проходили, а ты просто застрял на этом этапе. И, повторюсь, твое затуманенное эго тормозит тебя.
Вот тебе простой пример - создатель этого сайта Vantuz так же всё время изобретал свой велосипед. Тоже наверно считал себя крутым программистом. Но, как он сам писал, поработал он с rails и решил переписать движок на фреймворке fuelphp. Он сам сказал, что до фреймворков ротор/мотор был ущербным. А сейчас он идет по верному пути, респект. Он признал свою слабость и идет к силе. Ты же считаешь себя сильным, а на самом деле, таким же слабым и останешься.
И, повторюсь, это нормальный этап в карьере программиста. Большинство проходят через это. И я не исключение. И коллеги мои тоже.
58. Артур (20.05.2013 / 01:23)
))) хех. Бедный я. Вернемся к теме
59. Ant0ha (20.05.2013 / 01:24)
Возращайся)
60. Кевин Митник (20.05.2013 / 03:49)
Да уж, неплохо вы так пообщались) Позвольте и свои 5 коп вставить.
Холивары на тему "Готовые решения(фреймворки, ОРМ)" VS "Собственные разработки(читай "велосипеды")" будут всегда. Так что здесь все нормально. В споре рождается гриб, как говориться.
И да, уж вы то спорить не будете, иногда бывает, так называемые "велосипеды" иногда становятся популярными и известными. Просто разработчик не нашел чего-то, и решил написать свое. Теперь отвлечемся от темы и вспомним популярный веб-сервер Апач, который занимал 60% серверов(~160 млн сайтов). Но вот, в 2002 году выходит продукт Игоря Сысоева, Nginx, который вы все знаете. Сысоев разрабатывал сервер еще работая в компании Рамблер.
Осенью 2001 года у меня появилась идея написать более легкий и производительный веб-сервер, чем Apache. На тот момент были уже другие похожие серверы, но все они не умели проксировать, они отдавали только статику. Был у них еще один общий недостаток – они работали в одном процессе, и, соответственно, отмасштабировать их, допустим, на двухпроцессорной машине было нереально. На тот момент у меня уже был достаточно неплохой опыт работы с Apache — и как у системного администратора, и как у программиста. Два написанных модуля прибавили мне знаний: приходилось смотреть исходники Apache и понимать, как там все устроено. Поэтому очень многие вещи в nginx перекочевали из Apache идеологически. Не код, а именно идеология, весь код nginx был написан с нуля.
ТО есть его что-то не устраивало, он написал свой продукт. Теперь он на втором месте после Апача в мире(70млн сайтов).
61. юЮЮфюв (20.05.2013 / 06:45)
Мне нравится ActiveRecord в Ruby on Rails. Довольно простая вещь.
@post = Guestbook.new @post.author = current_user.login @post.message = params[:guestbook][:message]Как-то вот так.
62. Артур (20.05.2013 / 09:10)
60. Кевин Митник_HHTeam, самое интересное, что в процессе сей дискуссии я ни разу не упомянул и не намекнул на "Готовые решения(фреймворки, ОРМ)" VS "Собственные разработки(читай "велосипеды")", у меня даже в мыслях этой идеи не было, я за повторное использование кода )))
63. Ant0ha (20.05.2013 / 10:24)
60. Кевин Митник_HHTeam, бывают моменты, но такие случаи единицы. Ты тоже считаешь, что сейчас нет достойных ORM? Тоже думаешь, что ORM реализующие ActiveRecord, как сказал Башка, "недоORM"? Да с того Rails опять же, как подсказывает Dantes.
Автор ведь даже не знает как с ними работать и при этом говорит, что они ему не подходят. Тут немного разные вещи.
Я всего лишь высказал свое мнение, может оно жестковатое, но оно такое. Автор не первый и не последний.
64. Артур (20.05.2013 / 10:26)
Я писал AR и не знаю как с ними работать ))) интересно )))
65. Ant0ha (20.05.2013 / 10:33)
Башка (20 Мая 2013 / 10:26)
Я писал AR и не знаю как с ними работать ))) интересно )))
прикрепляй к следующему сообщению, глянем
Добавлено через 05:12 сек.
и я имел ввиду, что ты не можешь работать с готовыми орм на ar
66. Артур (20.05.2013 / 10:40)
Ты ж мне сам ссылки кидал )))) я уже кажись и удалил у себя полученное в результате чудо, а в теме должно остаться было.
Если настаиваешь, когда я реализую декоратор на мою ORM, скину примерчик, думаю ты даже не поймешь что это не AR )
67. Ant0ha (20.05.2013 / 10:49)
давай, скидывай. некогда мне тут больше ерундой страдать. пойду поработаю на "недоORM" пока.
68. Артур (20.05.2013 / 10:51)
Ок )))
69. юЮЮфюв (20.05.2013 / 14:19)
А собственно, даже если ActiveRecord это недоORM, то что мешает вам использовать не ORM? Религия?
70. Артур (20.05.2013 / 18:15)
Абстракция. ActiveRecord работает на уровне БД, а DataMapper на уровне объектов. Другими словами при использовании DM я забываю структуре БД и сосредотачиваюсь на программировании
71. Ant0ha (20.05.2013 / 21:15)
Решил плотнее познакомиться с Symfony 2, дошел до Doctrine. Оказывается она как раз таки реализует DataMapper. Можешь заюзать, если для тебя так важно использовать DM, библиотека может использоваться отдельно от фреймворка.
Вот краткое описание:
http://symfony-gu.ru/documentation/ru/html/book/doctrine.html
Добавлено через 04:15 сек.
Как по мне AR удобней, но это уже субъективно.
72. Артур (20.05.2013 / 21:33)
Посмотрю реализацию обязательно
73. Артур (20.05.2013 / 21:57)
Прочитал, реализация в точности такая же, как и у меня. Еще прикручу туда AR декоратор и будет отлично. А может лучше не прикручивать, а добавить реализацию AR отдельно от DM, кому что нравиться, тот тем и пользуется?
Добавлено через 01:11 сек.
Планирую еще реализовать подобие JPQL, это замечательный механизм
Добавлено через 08:11 сек.
Там даже Proxy используется, молодцы ребята, не нравиться только реализация множественных ассоциаций через методы, почему не через множества?
Добавлено через 09:10 сек.
И еще, все таки придется возиться с иерархически-организованными объектами, у меня же данная задача автоматизированна. Хотите толковую ORM, используйте Doctrine! )
74. Жан-Глюк Петард (24.05.2013 / 14:27)
DataMapper Fapper detected 8)
75. Владислав (24.05.2013 / 15:17)
Doctrine 2 это же калька с Hibernate, там даже весь API идентичен, только с поправкой на РНР синтаксис.
Только вот юзать её лучше тогда, когда ты сам понимаешь что тебе нужна именно доктрина. Для большинства задач в веб, она просто избыточна.
З.ы: ActiveRecord - это RAD принцип, очень удобная вещь, когда нужно просто "ехать", а не шашечки
76. Артур (24.05.2013 / 19:42)
Что в нем удобного?
77. wapmorgan (24.05.2013 / 21:22)
решил отметиться в эпичном треде
78. Ant0ha (25.05.2013 / 00:33)
wapmorgan (24 Мая 2013 / 21:22)
решил отметиться в эпичном треде
а ты нет?
Добавлено через 02:14 сек.
Башка (24 Мая 2013 / 19:42)
Что в нем удобного?
да, хотя бы то, что нужно работать всего с одним объектом. и не заморачиваться над всякими репозиториями и менеджерами.
79. Артур (25.05.2013 / 14:45)
В DT тоже с одним объектом ты работаешь + не задумываешься о физической структуре БД. Так чем удобнее то? ну?
Добавлено через 02:10 сек.
Ant0ha (25 Мая 2013 / 00:33)http://ru.wikipedia.org/wiki/Золотой_молоток
да, хотя бы то, что нужно работать всего с одним объектом
http://ru.wikipedia.org/wiki/Божественный_объект
напомнило )))
80. Владислав (25.05.2013 / 15:01)
О стуктуре данных ты и в том и в другом случае будишь задумываться, как ни крути. Просто АR - это прямая обьектная проекция бд. DМ, тут спорить безсмысленно, даёт более высокий уровень абстракции.
По сабжу: ты делаешь ОRМ, в основу адхитектуры ты взял DM, Unit Of Work, etc. Для данного подхода, описанное в первом посте АПИ весьма годно.
З.ы: Доктрина 2, уже(!) делает всё, и так, как тебе нужно. Если есть какие-то замечания/ЦУ, то м.б стоит примкнуть к сообществу и предложить доктриновцам свои разработки?
81. Артур (25.05.2013 / 15:14)
80. Limp, о структуре данных в AR случае задумываться приходится куда чаще ;)
АПИ то годное, но смущает удобство, может можно сделать удобнее нежели как есть (собственно вопрос темы, без ухода в чушь)?
Не могу себе позволить на уровне БД зависеть от сторонних разработчиков
хотел бы, да нельзя. Примкнуть я бы с радостью )
82. Ant0ha (25.05.2013 / 16:23)
79. Башка, ну, это уже крайности. Я немного не то имел ввиду.
83. Ant0ha (25.05.2013 / 16:38)
Башка (25 Мая 2013 / 15:14)
80. Limp, о структуре данных в AR случае задумываться приходится куда чаще ;)
Мне кажется ты просто не работал с нормальными реализациями AR, а только со своей.. Куча народу использует RoR, Django, Yii, Kohana и тп, которые используют AR и нет проблем. Всё-таки, у вас что то не то организацией кода.. Я думаю причина в том, что ты пытаешься всё сделать сам.
Добавлено через 02:31 сек.
Башка (25 Мая 2013 / 15:14)
Не могу себе позволить на уровне БД зависеть от сторонних разработчиков
Можно ведь наследовать, создавать форки и тп. И развивай как хочешь, нет зависимости ведь..
84. Владислав (25.05.2013 / 16:46)
""Планирую еще реализовать подобие JPQL, это
замечательный механизм""
Ты не поверишь, гг. Но у доктрины и это есть, называется DQL (Doctrine Query Language).
--
Прошу прощения, не знаю как тут отдельный текст цитировать.
85. Артур (25.05.2013 / 16:50)
Ant0ha (25 Мая 2013 / 16:38)
Мне кажется ты просто не работал с нормальными реализациями AR, а только со своей.. Куча народу использует RoR, Django, Yii, Kohana и тп, которые используют AR и нет проблем. Всё-таки, у вас что то не то организацией кода.. Я думаю причина в том, что ты пытаешься всё сделать сам.
Добавлено через 02:31 сек.
Можно ведь наследовать, создавать форки и тп. И развивай как хочешь, нет зависимости ведь..
Я думаю, причина в том, что ты не понимаешь концепции AR.
Можно конечно, переписывать код )))
Добавлено через 01:24 сек.
Limp (25 Мая 2013 / 16:46)
""Планирую еще реализовать подобие JPQL, это
замечательный механизм""
Ты не поверишь, гг. Но у доктрины и это есть, называется DQL (Doctrine Query Language).
--
Прошу прощения, не знаю как тут отдельный текст цитировать.
Чегож не поверю, видел, оценил! А как у доктрины с наследованием сущностей, м? )))
86. Владислав (25.05.2013 / 16:55)
85. Башка, сущности в доктрине - это обычные, чистые (т.е не потомки какого-то, определённого супер класса) РНР классы. Так что с наследобанием никаких проблем быть не должно.
87. Ant0ha (25.05.2013 / 16:56)
Башка (25 Мая 2013 / 16:50)
Я думаю, причина в том, что ты не понимаешь концепции AR.
Ага, как и остальное "стадо", использующее ее.)
88. Артур (25.05.2013 / 16:56)
Я о другом, как они записываются в базу? Вот есть у меня:
class User{
private $login;
private $pass;
}
а у моего сотрудника расширение:
class Admin extends User{
private $x;
}
Как объекты Admin пишутся в базу и как обрабатываются?
Добавлено через 00:35 сек.
Ant0ha (25 Мая 2013 / 16:56)http://lurkmore.to/Миллионы_не_могут_ошибаться
Ага, как и остальное стадо, использующее ее.)
89. Жан-Глюк Петард (25.05.2013 / 16:58)
Чем больше я читаю на форумах посты Башки, тем больше у меня укрепляется мнение, что это сферический конь в вакууме теоретической информации)
90. Ant0ha (25.05.2013 / 16:59)
QwAk (25 Мая 2013 / 16:58)
Чем больше я читаю на форумах посты Башки, тем больше у меня укрепляется мнение, что это сферический конь в вакууме теоретической информации)
Астронавт Архитектуры, я об этом писал уже.
91. Артур (25.05.2013 / 16:59)
89. QwAk, Спасибо )
92. Владислав (25.05.2013 / 17:06)
87. Башка, я таким не занимался никогда, не вижу смысла даже, но логика подсказывает что расширяемая сущность унаследует все свойства и они будут мапится б базу
93. Артур (25.05.2013 / 17:10)
Но таблица то одна, в какие поля попадут эти новые свойства?
Добавлено через 00:31 сек.
Почему ж не видно смысла? Смысл вполне ясен, расширение через наследование. Очень частая операция, особенно при разработке расширений на проект
94. Ant0ha (25.05.2013 / 17:17)
93. Башка, опиши схему работы над проектом. Что и как делаете. Может быть проблема как раз в организации этого процесса?
95. Владислав (25.05.2013 / 17:17)
Я что-то уже х.з что и как обьяснять.
Вобщем, таблица там может быть указана анотацией (в док.блоке), свойства будут писаться в одноимённые пол9 в БД.
Или ты хочешь, что бы при добавлении свойства в сущность, стр.ра бд автоматически перестраивалась?
96. Артур (25.05.2013 / 17:17)
Над каким проектом?
97. Ant0ha (25.05.2013 / 17:19)
Башка (25 Мая 2013 / 17:17)
Над каким проектом?
Типовым.
98. Артур (25.05.2013 / 17:23)
95. Limp, есть под рукой работа Фаулера?
Добавлено через 02:43 сек.
97. Ant0ha, анализируем задачу, создаем проектную документацию, раскидка часов, собираем шаблон проекта (gradle ext), инициализируем репу, каждый программист выполняет свою работу, модульное тестирование, мерджим форки, системное тестирование, опытная эксплуатация, промышленная эксплуатация
99. Владислав (25.05.2013 / 17:38)
Башка (25 Мая 2013 / 17:23)Нет, нету. Я как-то не был готов к столь фундаментальной дискуссии,
95. Limp, есть под рукой работа Фаулера?
.
100. Артур (25.05.2013 / 17:41)
http://design-pattern.ru/patterns/single-table-inheritance.html
http://design-pattern.ru/patterns/class-table-inheritance.html
У них там вроде первый подход, а у мну второй
Добавлено через 01:11 сек.
Ant0ha (25 Мая 2013 / 17:17)Открываю блокнот и начинаю писать главную, потом регистрацию, модирку, проверяю на дири ))) извини, не смог удержаться
93. Башка, опиши схему работы над проектом. Что и как делаете. Может быть проблема как раз в организации этого процесса?
101. Ant0ha (25.05.2013 / 17:43)
Как смешно, прям юморист.
102. Артур (25.05.2013 / 17:44)
)))) банально. знаю, знаю...
103. Владислав (25.05.2013 / 18:00)
100. Башка, понял. Ну да, доктрина будит писать всё в одну таблицу.
Связи сущностей организовываются тем же способом? Имею ввиду HasOne, HasMany, BelongsTo, etc.?
Хотя не, это не то.
104. Артур (25.05.2013 / 18:07)
Связи на уровне наследования OneToOne через OID, связи на уровне объектов OneToOne через Proxy с сериализацией и десериализацией через LazyLoad, а ManyToMany (как и 1..N) через аннотацию свойств, которые автоматически заполняются через LazyLoad SplObjectStorage
Добавлено через 01:07 сек.
Я просто не в состоянии был переписывать архитектуру доктрины под "наследование таблиц", все остальное было в ней отлично
105. Владислав (25.05.2013 / 18:11)
Реализация уже есть? Хотелось бы увидеть код.
106. Артур (25.05.2013 / 18:14)
Да, конечно. Могу модульные тесты скинуть, там видно принцип работы
Добавлено через 01:34 сек.
Я в процессе реинженеринга, но могу закомитить изменения и дать ссылку на гит
107. Владислав (25.05.2013 / 18:21)
Да, конечно комить на гит, код и тесты,
108. Саня (25.05.2013 / 18:23)
Использую ActiveRecord + Rails. Удобно и понятно
109. Артур (25.05.2013 / 18:38)
https://github.com/Bashka/PPHP.git
Предупреждаю еще раз, последний коммит в состоянии реинженеринга системы!
Смотри PPHP/tools/patterns/database и PPHP/tools/classes/standard/storage/database. Тесты по аналогичному пути в PPHP/tests
110. Ant0ha (26.05.2013 / 11:36)
К чему .idea в репозитории?
111. Артур (26.05.2013 / 11:41)
Как то раз по запаркам удалил у себя проект, восстановил из репы и пришлось восстанавливать настройки. После этого засовываю .idea в репу всегда + автоматом проставляется стандарт форматирования кода.
Пора переименовать тему в "Самая удобная ORM в мире" )))
Вчера добавил композитную связь и Full подгрузку
112. Ant0ha (26.05.2013 / 12:03)
Башка (26 Мая 2013 / 11:41)
Пора переименовать тему в "Самая удобная ORM в мире" )))
Давно пора).
113. Ant0ha (26.05.2013 / 13:34)
Лучше тогда сразу "Величайшая ORM в мире" чтобы лишний раз не переименовывать)
URL: https://visavi.net/topics/37909