Вы используете ORM в реальной практике?

[varan]

Вы используете ORM в реальной практике?

Варианты ответов
1) Да, использую постоянно, и только ORM
2) Нет, никогда не использую, все запросы составляю сам
3) В части проектов так, в части эдак
4) Использую некий гибрид

 

[флоппик]

Тут еще стоит уточнить вопрос о готовых орм библиотеках, или нет.
Т.к. ОРМ можно делать и без чужих либ, просто описывая обьекты и пряча в них обычный SQL

 

[Ragazzo]

Doctrina

 

[akd]

использую свой недоорм в части проектов для самых простых задач (в основном справочники и простенькие формочки без глубокой логики)

 

[StUV]

5) все запросы в хранимых процедурах/функциях (относительно статичный интерфейс взаимодействия с пхп-кодом, структура данных и логика обработки инкапсулированы в бд)

 

[atv]

Использую, но не только ОРМ. Т.е. у меня есть чёткое разграничение где применять ОРМ, а где запросы, в рамках одного проекта.

 

[Духовность™]

У меня свой недоORM, совершенно простой. Один объект - одна строка таблицы.

ПС товарищи, кидайте код примеров свои недоОРМ!

 

[Alexandre]

varan

затрудняюсь выбрать между 2 и 4
2) Нет, никогда не использую, все запросы составляю сам
4) Использую некий гибрид

использую класс Модель, в которой прописаны шаблоны запросов.
по шаблонам стою и выполняю запросы. Все существующие ОРМ мне не нравятся. И вообще мне не нравится подход ОРМ.
да и отладка с ОРМ - геморойное дело.

но на работе у нас используют кохану и ЗФ, так что приходится использовать

 

[craz]

Zend_DB ORM - всегда хотел занть...?

 

[newARTix]

craz
Zend_Db_Table скорее ближе к ActiveRecord, насколько я понимаю. А Zend_Db тут вообще не при делах вроде, это конструктор запросов.

 

[korchasa]

newARTix
Это TableGateway, т.к. не скрывает своей табличной сущности и оперирует массивами, а не объектами.

 

[craz]

спасибки, а то сморозил бы где нить)))

надо все таки потрогать доктрину, или TableGateway альтернативная и одинаково продвинутая технология?

 

[A1x]

http://zendframework.com/manual/en/zend.db.table.html
у них там прямо в доке ссылки на описания соответствующих паттернов

 

[LONGMAN]

Преимушества какие у ORM? И как обстоит дело когда нужно делать джойны нескольких таблиц?

 

[korchasa]

LONGMAN
Прозрачная работа со связями, сложное прозрачное кастование строка->объект и обратно, автоматическая валидация, отложенная загрузка коллекций/объектов/полей, и все такое прочее, истекающее из того, что клиентский код работает с бизнес объектами, а не со строками. В общем проще попробовать, чем все написать.

Насчет join'ов, про остальных не скажу, но у нас есть, могу отсыпать.

 

[Wicked]

1)

propel - стаж 2 года

 

[craz]

подскажите где почитать вменяемую статью ZF1.10 + Doctrine2 можно на англ. главное чтоб развернутая была

 

[A1x]

Автор оригинала: LONGMAN
Преимушества какие у ORM? И как обстоит дело когда нужно делать джойны нескольких таблиц?

как раз изучаю ORM Kohana - кроме Relationships (http://kohanaframework.org/guide/tutorials.orm)
можно еще динамически джойнить в модель аттрибуты из других таблиц, примерно так:

$tt = Model::factory('test')
                ->select('td.comment')
                ->join(array('test_data', 'td'), 'LEFT')->on('test.id', '=', 'td.test_id')
                ->find_all();

по теме поста: использую ORM постоянно, так как позволяет делать более компактный и удобный в поддержке код,
если неудобно какой-то запрос делать через ORM использую обычные запросы

раньше тоже использовал свой ORM велосипед но он уже морально устарел

 

[флоппик]

Это не ОРМ, это обьектная обертка над SQL.
ОРМ это когда ты проецируешь данные из БД на обьект, который реализует какую-то предметную область приложения, скрывая нижележащую систему хранения: таблицы, и отношения между ними.. Это не обязательно должна быть готовая библиотека, все, что скрывает SQL-запросы к бд, давая управлять взамен сущностями приложения и есть орм.

 

[A1x]

флоппик
ну так и тут данные из бд проецируются на объект предметной области. то о чем вы говорите похоже на Data Mapper, а в kohana ORM сделан на Active Record

Можно спрятать конструкции query builder'a в модель отдельным методом, как-то так
$tt = Model::factory('test')->joinTestComment()->find_all();

вообще можно пытаться как можно больше абстрагироваться от SQL, но так ли уж это надо?