Форум программистов [Powered by Invision Power Board]

Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > Perl: Общие вопросы > Perl ORM

Автор: sir_nuf_nuf 15.4.2008, 17:13

Комрады!

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

Кто может высказать по следующим библиотекам?

Tangram
Rose: smile

B::Object
Class::DBI
DBIx::Class
SPOPS
Hibernate (не перловая, но я думаю для сравнения нужно и ее описать)

Что бы удобнее было сравнивать оценивайте плиз следующие критерии:

0) удобство использования
1) возможность работать с готовыми классами без их изменения
2) возможность работать с готовой схемой БД без ее изменения
3) качество генерируемых схем (понятные имена таблиц и т.п.)
4) качество генерируемых запросов (скорость работы, тонкие места SQL)
5) переносимость между БД
6) возможность встраивать свои код сохранения/загрузки
7) фичи библиотек..

Если есть дополнения к списку критериев, пишите.

Автор: sir_nuf_nuf 23.4.2008, 00:09

Ну что же никто не отвечает..

Приведу резалты нашего семинара по perl ORM.

SPOPS - умер давно, а в том который был было столько багов ( вплоть до незащищенности от injection). НЕ ЮЗАТЬ.

Class::DBI и DBIx::Class - внешне очень похожие фреймворки, второй есть улучшение первого (по крайней мере
так написано в доках) так что если изучать - то скорее сразу второй.
Эти фреймворки - есть ОБЕРТКА НАД БД. Т.е. в центре внимания лежит схема БД. Именно схема БД определяет структуру классов.
Как и все пакеты из Class::* Class::DBI сама создает необходимые мутаторы (и аксесоры) в классе по заданной таблице
Есть возможность писать SQL если не хватает возможностей ОРМ.
Плюсы: совместимость с готовой схемой БД. Идеально для построения Объектно-ориентированного интерфейса доступа к БД
Минусы: генерирует свои классы, Если уже есть классы моделирующие бизнес-сущности - нужно будет строить адаптеры и т.п.

Tangram - очень интересный ОРМ, советую обратить на него внимание..
Основная фича - абсолютный отказ от SQL. Вам его просто не придется писать.
Вторая важная фича - ортогональность классам. Т.е. классы сохраняемые в базу ничего не знают о том что их сохраняют!
нет необходимости наследоваться или добавлять методы. Мы можем сохранять готовые классы! Единственно ограничение - объекты должны быть ссылками на хэши.
Tangram сам генерирует схему БД с которой он будет работать. Поддерживает наследование.
Плюсы: очень удобно при разработке проекта с 0. Продумываете сложную бизнес - модель , и не парьтесь с БД.
Минусы: те же. Вы не контролируете схему БД, что иногда просто не приемлемо. Однако вы можете взять схему танграма и доработать "напильником"

Rose:B::Object - еще одна вариация на тему Class::DBI. Является частью веб - фреймворка Rose:: Пока еще находится в стадии разработки. сырой. Есть фича: удобный мультиплексор DBI соединений.

Большинство ОРМ в той или иной мере поддерживают Lazy Loading, кэширование.
Совместимость с БД - примерно одинаковая у всех MySQL, Postgres, SQLite, Oracte.
Некоторые держат Sybase (смотри доки)

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

Автор: Ромыч 29.4.2008, 03:48

Про DBIx::Class. На самом деле он может генерировать схему БД на основе классов. И даже делать diff-ы при изменении этих классов, правда тут он не поддерживает enum и вообще иногда ошибается, sql скрипты приходится иногда допиливать после него... Но работать с ним в стиле, когда структуру БД полностью определяет код, вполне можно.

Автор: Nab 26.6.2008, 06:24

Есть такая штука PerlORM

http://search.cpan.org/~akimov/ORM-0.85/
http://sourceforge.net/projects/perlorm/

Автор: gcc 19.7.2008, 12:50

Автор: gcc 19.11.2008, 21:49

понравлось пользоватся DBIx::Class

при построении программных запросов этой штукой разве удобно писать?

вродебы не спасает от удобства, все равно нужно писать, в принципе, одинаково... if elsif else

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

как еще такое можно написать?

Код


if ($s ==1) {push @clausers "User = $s";
if ($s ==2) {push @clausers "User = $s";}
if ($s) {push @clausers "User = $s";}
if ($s) {push @clausers "User = $s";}
if ($s) {push @clausers "User = $s";}
} esle {
if ($s) {push @clausers "User = $s";}
}
$clause = join (" AND ", @clauses );
$sth = $dbh->prepare(SELECT * FROM table WHERE $clause );

Автор: Logo 28.12.2010, 15:13

Возвращаясь к вопросу. Есть ли нормальные ORM под Perl? Пользовался DBIx::Class, однако он не аккуратно строит запросы. Во первых, игнорирует выбор полей в prefetch, выбирая сразу все поля из всех таблиц. Во вторых добавляет в запрос странный "order by ключ таблицы", что при некоторых обстоятельствах приводит к провисанию базы. Еще меня не устраивает что join можно сделать только по заранее созданому правилу в Relationship, то есть нельзя выбрать inner join или outer join, только тот который в Relationship, хотя это меньшая проблема.

Автор: myth777 28.12.2010, 18:02

Нормальных ОРМ, сколько не искал, так и не нашел. Везде где то чего то не хватает.
Написал свой. Пользуюсь уже им 2 года, постоянно совершенствую его.
Вот его начинка:
1. Обертка вокруг таблицы(DBI);
2. События наружу типа просмотра, редактирования, добавления и др..;
3. В качетсве шаблонизатора HTML::Template
4. Класс который может компоновать обертки и делать общую(для представления нескольких таблиц в одной)
5. Чековалка на проверку ввода(потдерживает ajax запросы)
Вот вроде основное..

Автор: sir_nuf_nuf 28.12.2010, 19:10

Цитата(myth777 @ 28.12.2010, 18:02)

И что из этого ORM ? Это целый фреймворк =)

А можно на него посмотреть ? на CPAN выложен ?

Автор: myth777 30.12.2010, 15:43

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

Автор: gcc 1.1.2011, 10:40

Insert, update и простые select запросы можно писать в абстрации в какой-то... (SQL::Abstract, RoseDB, DBIx::Class, etc)
а все остальные в нативном виде, в /model/MySQL/table.pm
это не подходит?

Insert, update - пишутся в одну строку....
генератор простых SQL запросов, тоже, можно написать

есть сложные запросы в PostgreSQL, которые не написать в какой либо ORM

inner join на MySQL все пишут c пересечением по id:

Код


... from table as t1, 
            table2 as t2 
  where t1.id = t2.id