Комментарии 33
Спасибо за статью.
Несколько вопросов:
#1 Насколько вменяемый получается результирующий SQL (кстати, можно ли его как-то увидеть в отладочном режиме)?
#2 Есть ли возможность декларативного задания отношения между сущностями (ассоциация, агрегация)?
#3 Как обстоят дела с управлением транзакциями?
Несколько вопросов:
#1 Насколько вменяемый получается результирующий SQL (кстати, можно ли его как-то увидеть в отладочном режиме)?
#2 Есть ли возможность декларативного задания отношения между сущностями (ассоциация, агрегация)?
#3 Как обстоят дела с управлением транзакциями?
#1 есть режим отладки, включается R::debug(true);
#2 насколько я понял, тут только между готовыми объектами можно задавать отношения. Или я ваш вопрос не понял.
#3 Про транзакции нашел только в wiki
#2 насколько я понял, тут только между готовыми объектами можно задавать отношения. Или я ваш вопрос не понял.
#3 Про транзакции нашел только в wiki
Я так понимаю эта ORM нужна для ознакомления с Active Record, ибо для продакшена она не годится :)
Насколько я понимаю, тут не Active Record (у объектов нет метода save() — их сохраняет другой объект). А продакшен — смотря какой продакшен. Я использовал первую версию в небольшой задачке, где пользователь заполнял довольно длинную форму и надо было все данные хранить в БД, чтобы потом пользователь мог продолжить заполнение или получить еще раз результат обработки своих данных. Там, как мне кажется, RedBeanPHP замечательно вписался с его import($_POST)
Подойдет для проектов на скорую руку.
для быстреньких штук самое оно, в закладки :)
Не люблю ORM, но в этом что-то есть… Спасибо
Прошлой весной ковырял RedBean долго и упорно. Идея тотальной простоты и работоспособности из коробки очень понравилась, но поверх этой идеи оказалось накручено много мути.
Например, работа с ассоциациями мне сразу показалась подозрительной. С версии 1.3 до 2.0 все поменялось, но что тогда что сейчас все ассоциации выражены через many-to-many, что (на мой взгляд) чудовищно. Автор же считеат это преимуществом: мол вы можете ассоциировать что угодно с чем угодно. В версии 2.0 появились две странные фичи (nested beans и on-the-fly views) для тех, кому не нравилось, что любая ассоциация требует junction table.
То есть с одной стороны имеем тривиальный active record, и используем old good SQL (в старой доке была фраза «Some tools even promote their own version of SQL. To me this sounds incredibly stupid. Why should you use a system less powerful than the existing one? This is the reason that RedBean simply uses SQL as its search API.») С другой стороны, чтобы связать Product с Category приходится поступать куда более «incredibly stupid».
Для добавления логики к моделям используется нечто под названием «fuse» (данные и логика живут отдельно). На первый взгляд приколько, но на второй понимаешь, что от этого только проблемы (теряется инкапсуляция; тихо игнорируется вызов несуществующего метода...)
Напрягает наличие в базовой поставке каких-то экзотических вещей вроде Cooker и BeanCan Server.
RedBean может глотать исключения там, где этого делать не надо: tinyurl.com/c3yanmp
И один раз мне пришлось долго убеждать автора в том, что нельзя считать ноль и пустую строку эквивалентными данными: tinyurl.com/d6d3m8v
В целом у меня возникло ощущение, что RedBean — это полигон, на котором автор пробует всякие прикольные идеи, но большого доверия качество исполнения во мне не вызвало. Возможно, дело в том, что автор голландец и курит перед написанием кода…
Однако RedBean меня вдохновил, и я попытался сконцентрировать понравившиеся мне идеи в моем собственном проекте, который назвал orange-bean. Кому интересно, вот ссылка: code.google.com/p/orange-bean/
Например, работа с ассоциациями мне сразу показалась подозрительной. С версии 1.3 до 2.0 все поменялось, но что тогда что сейчас все ассоциации выражены через many-to-many, что (на мой взгляд) чудовищно. Автор же считеат это преимуществом: мол вы можете ассоциировать что угодно с чем угодно. В версии 2.0 появились две странные фичи (nested beans и on-the-fly views) для тех, кому не нравилось, что любая ассоциация требует junction table.
То есть с одной стороны имеем тривиальный active record, и используем old good SQL (в старой доке была фраза «Some tools even promote their own version of SQL. To me this sounds incredibly stupid. Why should you use a system less powerful than the existing one? This is the reason that RedBean simply uses SQL as its search API.») С другой стороны, чтобы связать Product с Category приходится поступать куда более «incredibly stupid».
Для добавления логики к моделям используется нечто под названием «fuse» (данные и логика живут отдельно). На первый взгляд приколько, но на второй понимаешь, что от этого только проблемы (теряется инкапсуляция; тихо игнорируется вызов несуществующего метода...)
Напрягает наличие в базовой поставке каких-то экзотических вещей вроде Cooker и BeanCan Server.
RedBean может глотать исключения там, где этого делать не надо: tinyurl.com/c3yanmp
И один раз мне пришлось долго убеждать автора в том, что нельзя считать ноль и пустую строку эквивалентными данными: tinyurl.com/d6d3m8v
В целом у меня возникло ощущение, что RedBean — это полигон, на котором автор пробует всякие прикольные идеи, но большого доверия качество исполнения во мне не вызвало. Возможно, дело в том, что автор голландец и курит перед написанием кода…
Однако RedBean меня вдохновил, и я попытался сконцентрировать понравившиеся мне идеи в моем собственном проекте, который назвал orange-bean. Кому интересно, вот ссылка: code.google.com/p/orange-bean/
Хотел поближе посмотреть на orange-bean…
А в чем смысл компресии вашего класса через php-compressor?
я думаю многие были бы благодарны, если исходник сразу был бы в удобно-читаемом виде.
А в чем смысл компресии вашего класса через php-compressor?
я думаю многие были бы благодарны, если исходник сразу был бы в удобно-читаемом виде.
Исходники не прячу: code.google.com/p/orange-bean/source/browse/#svn%2Ftrunk
Смысл — просто обкатываю компрессор (он тоже мой) на этом проекте.
Смысл — просто обкатываю компрессор (он тоже мой) на этом проекте.
Круто, но почему бы не следовать зендовым стандартам? framework.zend.com/manual/ru/coding-standard.coding-style.html.
НЛО прилетело и опубликовало эту надпись здесь
А ни у кого нет случайно списка PHP ORM, которые реализуют любой шаблон кроме ActiveRecord?
(приелось и хочется чего то более экзотического)
(приелось и хочется чего то более экзотического)
За что минусуют? ActiveRecord не всегда удобно использовать да и кроме него есть еще несколько более сложных, но и более удобных шаблонов (data access object, table data gateway, row data gateway, data mapper и т.д.). Было бы интересно увидеть их реализацию.
Doctrine2 — DataMapper + ещё куча паттернов. Лично мне кажется самым удобным, т. к. классы и модели объектов самые обычные PHP-классы, никак не привязанные ни то что к схеме БД, но даже к системе хранения в целом.
Если бы мы решили сохранить число в одном из свойств ($book->price = 100), то RedBeanPHP выбрал бы тип TINYINT(3) для хранения этого свойства. Если потом нам надо будет сохранить дробную цену, то RedBeanPHP на лету поменяет тип поля в БД.Отсюда сразу следует, что это только для небольших игрушек. Где-нибудь не досмотрит программист, пропустит float и этот ОРМ начнёт шуршать таблицей, блокируя туда запись, перестраивая индекс, если таблица большая, это может повесить всё на минуты, а то и десятки минут.
Там есть режим блокировки изменений в схеме данных. Отключается одной командой, после этого ОРМ схему днных не трогает.
Спасибо. А как-то можно указать, что мне для текстовых данных мало varchar(255)?
Этого нельзя. Подразумевается, что после freeze вы внимательно посмотрите получившуюся схему и «расширите» типы колонок там, где получилось «мало»:
www.redbeanphp.com/manual/freeze
www.redbeanphp.com/manual/freeze
А еще есть замечательная библиотека IdiORM
Мини- ORM, состоящий из одного файла. Очень рекомендую.
Мини- ORM, состоящий из одного файла. Очень рекомендую.
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
RedBeanPHP — еще одна ORM библиотека