BugzillaORM — различия между версиями
| Строка 15: | Строка 15: | ||
Есть и сложный путь — использование языка запросов типа [[rupedia:Language_Integrated_Query|LINQ]] или [[Funq]]. Ради решения этих трёх проблем они и был задуманы. | Есть и сложный путь — использование языка запросов типа [[rupedia:Language_Integrated_Query|LINQ]] или [[Funq]]. Ради решения этих трёх проблем они и был задуманы. | ||
| − | Тем не менее, | + | Тем не менее, ORM’а всё равно хочется. Даже Bugzilla имеет своё подобие ORM’а. ''Почему?'' |
| − | * {{CPAN|SPOPS}} | + | А вот некоторый обзор существующих модулей ORM: |
| − | * {{CPAN|DBIx::Class}} | + | |
| − | * {{CPAN|Class::DBI}} | + | * {{CPAN|SPOPS}} — ужас кривой, тормозной, неиллюзорный, заброшенный в 2004 году. |
| − | * {{CPAN|DBR}} | + | * {{CPAN|DBIx::Class}} — лидер области. Тяжеловесный, имеет кучу возможностей и вторую кучу — зависимостей. Например, использует {{CPAN|mro}} 'c3'. Частично совместим с Class::DBI. Но вы как хотите, а «БД-независимый» язык запросов, основанный на хешах — это ад. Что-то типа Vsem::DB::Query из [http://www.vsem.ru vsem.ru], кстати. |
| + | * {{CPAN|Class::DBI}} — говорят, легковесный. Наиболее старый — родился в 2001 году. | ||
| + | * {{CPAN|DBR}} — весьма похож на Funq. Но явно попроще. Наиболее, кажется, «альтернативный». | ||
| + | * {{CPAN|Rose::DB::Object}}. | ||
| + | * {{CPAN|Class::AutoDB}}. | ||
| + | |||
| + | А вот ещё одна почти бессмысленная возможность: итераторы. Даже {{CPAN|DBR}} её, кстати, не лишён. То есть она осмысленная — в GUI-приложениях. Но не в веб-приложениях, где сам DBI, во-первых, никогда не держит открытых курсоров, во-вторых, это часто не даёт делать СУБД, а в-третьих, это совершенно не нужно, так как время исполнения запроса должно быть как можно более малым, а следующий запрос уже вряд ли попадёт в тот же поток (или вообще процесс). | ||
[[Категория:Разработка]] | [[Категория:Разработка]] | ||
Версия 01:24, 8 сентября 2009
Здесь, наверное, будет статья, в которой я постараюсь выразить свои мысли по поводу ORM, обычного взгляда на вещи и необычного взгляда на вещи.
А пока что это сборище идей.
Пример: http://rutube.ru/tracks/793494.html - доклад с YAPC::Russia. Автор Егор Шиповалов, название Применение ORM в Perl.
Первый же слайд ясно даёт понять проблемы, обычно решаемые с помощью объектно-реляционных мапперов:
- Дублирование кода работы с БД.
- Трудоёмкость адаптации кода под изменения схемы и различные СУБД.
- Необходимость знания устройства и работы с БД всеми программистами команды.
Строго говоря, всё это «4ёрта.с.2». Тривиальный путь решения всех трёх проблем: код работы с БД для каждого «компонента» программы выносится в отдельный класс и разбивается на отдельные процедуры. При грамотном разбиении кода работы с БД на отдельные процедуры он получается достаточно компактным, а если не компактным, то по меньшей мере простым и очевидным. Весь код работы с БД таким образом становится сконцентрирован в одном месте, и переписывать под различные СУБД его становится гораздо проще. И уж конечно, имея код работы с БД в отдельном классе, неспециалисты по БД могут и не заниматься работой с ней.
Есть и сложный путь — использование языка запросов типа LINQ или Funq. Ради решения этих трёх проблем они и был задуманы.
Тем не менее, ORM’а всё равно хочется. Даже Bugzilla имеет своё подобие ORM’а. Почему?
А вот некоторый обзор существующих модулей ORM:
- SPOPS — ужас кривой, тормозной, неиллюзорный, заброшенный в 2004 году.
- DBIx::Class — лидер области. Тяжеловесный, имеет кучу возможностей и вторую кучу — зависимостей. Например, использует mro 'c3'. Частично совместим с Class::DBI. Но вы как хотите, а «БД-независимый» язык запросов, основанный на хешах — это ад. Что-то типа Vsem::DB::Query из vsem.ru, кстати.
- Class::DBI — говорят, легковесный. Наиболее старый — родился в 2001 году.
- DBR — весьма похож на Funq. Но явно попроще. Наиболее, кажется, «альтернативный».
- Rose::DB::Object.
- Class::AutoDB.
А вот ещё одна почти бессмысленная возможность: итераторы. Даже DBR её, кстати, не лишён. То есть она осмысленная — в GUI-приложениях. Но не в веб-приложениях, где сам DBI, во-первых, никогда не держит открытых курсоров, во-вторых, это часто не даёт делать СУБД, а в-третьих, это совершенно не нужно, так как время исполнения запроса должно быть как можно более малым, а следующий запрос уже вряд ли попадёт в тот же поток (или вообще процесс).
