ну вот в такой случае, может он и очевидный. и то не очень то PHP: ORM()->log[] = array('text'=>'В жопу *******'); хотя чего уж ОРМ, когда вон работу со строками переписывают...
ORM - хороший способ получить повторно используемый код, ибо ООП. Каждая запись - объект вашего класса. Simpliest Сейчас работает ORM()->User(1)->phone; В хотелках сделать рабочим ORM()->User[1], после чего заработает и ORM()->User[1]['phone']
Что одна и та же логика описана в одном конкретном месте а не в десяти разных местах. Нет. Количество кода - не то место которым меряются. Чем код понятней [другому] человеку тем лучше. -- ORM ускоряет разработку и проливает жизнь
скачать ORM v2.3 (69 Kb) + реализация ArrayAccess для добавления и удаления объектов + сериализация схемы в собственный формат + небольшие багофиксы Использование ArrayAccess: PHP: <?php // SQL: INSERT INTO user(nick, icq) VALUES('Ti', '177717007') ORM()->User[] = array('nick'=>'Ti', 'icq'=>'177717007'); // SQL: UPDATE user SET phone = '111' WHERE id = 1 ORM()->User[1] = array('phone'=>111); // SQL: DELETE FROM user WHERE id = 1 unset(ORM()->User[1]);
одно с другим не сочитается или ты про абстрагирование? дык орм тут как таковой не причём. любая обёртка сгодится согласен. основная задача - как можно меньшим кол-ом операций сделать одну и ту же задачу максимально быстро и эффективно в ч.с. это кол-во кода вот так глупость. бывает что по логике человека хорошо, то для приложения смерть
вообще наверно модели прописывать было бы удобно через YAML. Но я все равно пользуюсь простым класом и плейсхолдерами для экранирования/приведения типов
Koc да, в STRICT MODE MySQL будет работать. Ага, любая обертка, в том числе ORM. да, бывает. Также, чаще всего, оптимизация убивает понимание кода человеками. Иначе писали бы на ассамблере или даже делали бы одни хардварные решения.
ну да, но это не аргумент в пользу орма =) ну так ну и зачем тогда лишние проблемы, аля ОРМ? для тебя это может и не ОРМ, а обычная обёртка, однако со стороны это совсем другая логика работы с БД и поэтому не удобно в неё вникать
Mr.M.I.T. ORM поднимает уровень работы с базой с декларативного на ООП. А твои сомнения возникают из-за того что ты не ООП-инфицирован. Не хочешь — не ешь. Еще раз повторяю, этот топик не для флейма на тему "зачем нужен ORM?". Убеждать вас в том что вам не нужно мне не интересно. Этот топик развития конкретной реализации.
и чё теперь? обсуждать её нельзя? нужен не нужен, это как раз из этой оперы. я знаю что делает Обджект Релейшион Маппинг. чего я не? я и не собирался есть
В связи с анонсом релиза 2-й версии доктрины, представляю альфа версию нового ORM под названием pQL. Хомпейдж: http://ti.y1.ru/pql/ Примеры использования: https://github.com/Ti-webdev/pQL/wiki Главные отличия от других реализаций ORM: - нет необходимости определять схему - все информация достается из базы данных; - приятный интерфейс запросов; - реализация жадной выборки с помощью привязки переменных; - автоматическое объединение таблиц A и C в запросе, даже если они не связанны между собой напрямую Реализованы драйвера для PDO::MySQL, PDO::SQLite, MySQL Поддержка PHP 5.2+ (5.1+ для MySQL драйвера)
ну это преимущество с натяжкой. Можно сгенерировать схему по существующей базе или даже из воркбенча) ну и это активрекорд. И как я понимаю, там туева хуча магии.
Конечно преимущество! В чем удобство, каждый раз при изменении схемы в базе, перегенерировать схему в приложении? Или, если схема хранится в приложении и обновляет схему базы, сложно интегрировать ORM в существующее приложение. Можно и так сказать: ActiveRecord это синоним ORM с небольшим различием. Магия содержится лишь в использовании магических методов По большому счету, pQL просто транслирует записи из базы в приложение.
как я вижу процесс внесения изменений в структуру базы: 1) поменяли модель в воркбенче 2) сгенерировали новую схему 3) сравнили старую схему с новой, получили миграцию 4) накатили эту миграцию на дев/продакшн http://www.doctrine-project.org/project ... rations/en не обязательно. Вот та же доктрина2 DataMapper использует.
Не как ты видишь, а как приходится делать в доктрине Используя pQL нужно просто выполнить SQL меняющий структуру базы Реализация паттерна ActiveRecord так же может использовать внутри паттерн DataMapper ORM — технология программирования ActiveRecord — паттерн проектирования Да, я слукавил, сказав что это синонимы pQL является ORM, реализованный паттерном ActiveRecord
зато я смогу потом откатить эту миграцию). Если уж так хочется AR - можно реализовать http://www.doctrine-project.org/blog/yo ... ne2?id=157 В общем я не против своих велосипедов, сам страдаю этим (правда не в таких масштабах, у меня не получается писать что-то настолько серьезное и монументальное), но Доктрина2 - она что ли более надежная. Ей можно доверять, там куча тестов. У нее есть комьюнити. Уже появляются всеразличные расширения. Ты начинал писать свою ORM когда была только первая доктрина. Да, она откровенно говоря галимая. На то время может быть и был смысл этой затеи. Но с приходом второй версии все поменялось.
Koc Меня, честно говоря, сильнее всего волновали простота и удобства выбоки данных В доктрине и по сей день это, мягко говоря, через жопу^w DQL
вокруг него есть довольно мощный QueryBuilder. Я думаю с ним очень удобно делать динамические фильтры (как в Trac, Redmine)
QueryBuilder? именно что вокруг него. Doctirne (из мануала): PHP: <?php // example6: how to define: "SELECT u FROM User u WHERE u.id = ? ORDER BY u.name ASC" using QueryBuilder string support $qb->add('select', 'u') ->add('from', 'User u') ->add('where', 'u.id = ?1') ->add('orderBy', 'u.name ASC'); ->setParameter(1, 100); // Sets ?1 to 100, and thus we will fetch a user with u.id = 100 pQL (эквивалент предыдущему): PHP: <?php $query = db()->user->id->in(100)->name->ask(); При написании pQL я пользовал TDD, потому код хорошо или плохо протестирован
В пользу динамических фильтров: QUERY_STRING: ?table=user&filter[id][]=5&filter[id][]=6&filter[dateAdd]=22.12.2010&order[login]=desc&order[id]=asc PHP: <?php $query = db()->$_GET['table']; foreach($_GET['filter'] as $key=>$value) $query->$key->in($value); foreach($_GET['order'] as $key=>$order) $query->$key->$order(); foreach($query as $user) { echo $user; }
если значение одно то eq. SQL: ... WHERE field = $value если значений несколько (массив или несколько параметров) то используется in. SQL: ... WHERE field IN ($value1, $value2) метод называется in потому что eq разным значениям == WHERE false