Отзывы об использование ORM

[ваяс]

Хотелось бы услышать мнение людей об использовании каких-либо ORM?
Кому что нравиться?
В чём преимущества?
Или наоборот почему не используете?

 

[archcoffe]

имхо

Кому что нравиться?

- своя

В чём преимущества?

- знаю что и где в ней. Удобно для небольшого проекта

Или наоборот почему не используете?

- слабая необходимость.Также пробовал ko3 - не понравилось, просто не понравилось.

 

[ваяс]

- своя
- знаю что и где в ней. Удобно для небольшого проекта

А почему предпочли создание ORM вместо обычных SQL запросов?
Тем более проект небольшой.

 

[archcoffe]

А почему предпочли создание ORM вместо обычных SQL запросов?

- старший программист показывал, подсказывал, а я учился, - за что ему большое спасибо.

 

[С.]

А почему предпочли создание ORM вместо обычных SQL запросов?

Не бывает выбора ORM или SQL. ORM присутствует всегда в той или иной мере. Разница лишь в том, мэпишь ли ты сам или используешь какие-то сторонние продукты.

 

[Тугай]

То что в двух-уровневом клиент-сервреном приложении, программировалось на уровне субд (значения по умолчанию для полей, ссылочная целостность, хранимые процедуры, constraint, каскадные обновлени, удаления и т.д.
все это применительно к PHP+Mysql, зачастую делается на уровне PHP. С техничексой точки зрения это тоже оправдано, потому что это один сервер одни и теже ресурсы и можно считать что mysql - это бд с мнимальным функционалом.

Так что ORM, дает нам не только уровень абстракции работы с нашими моделями, но и выполняет много полезных функций, которые можно было бы реализовыать на уровне рсубд.
Когда у нас несколько разных источников данных с разными возможностями - ORM позволяет скрыть их преимущества и недостки за общими интерфесами.

ваяс
ORM - это не cоздание SQL запросов. Содание SQL запросов - это DBAL.
ORM - это виртуальная объектная база данных, частью которой (внутренним API) является DBAL.

В Doctrine есть DQL, в Java Persistent API свой похожий язык работы с этой виртуальной базой объектов.
DQL - не заменяет SQL, это другой уровень. Когда нужно использовать DQL вместо SQL ? Ну тогда когда станет очевидным, что от этого есть профит.

Вполне можно обходится и без "DQL", создавая свои сервисы, используя DBAL нашей ORM, фактически расширяется язык доступа к виртуальной объектной базе, реализуя всякие частные случаи.

 

[ваяс]

Когда у нас несколько разных источников данных с разными возможностями - ORM позволяет скрыть их преимущества и недостки за общими интерфесами.

Это большая редкость в моей практике, в основном я использую только MySQL
Т.е. если я использую основные операции с базой нет смысла в использовании ORM?
Если всё таки есть не могли бы вы пример мне показать, на примере какого-нибудь SELECT запроса.
Допустим таких селектов в моём приложении десятки. Фильтры, пейджинг, выборка еденичной записи и т.д.
В чём было бы преимущества использования ORM хотелось бы расширить свои познания.

 

[Gas]

Т.е. если я использую основные операции с базой нет смысла в использовании ORM?

как раз наоборот, для базовых операций orm отлично работает
пример одного из orm
http://four.laravel.com/docs/eloquent

 

[archcoffe]

однако

реализуя всякие частные случаи

порой становится грустно=)

 

[Absinthe]

Понравилась Eloquent ORM. За то, что слизана с рельсов.

 

[флоппик]

почитал доки. А оно выковыривается из ларвы, никто не пробовал?

 

[Тугай]

ваяс
Хотите seleсt ?
ОРМ это не технолония будущего - это прошлое. Как бы грустно это не звучало, запрос типа вабрать все дукументы, где постащик такой-то - это давано есть, напирмер в 1C 7.x.
В контексте

Допустим таких селектов в моём приложении десятки. Фильтры, пейджинг, выборка еденичной записи и т.д.

Куда они отностся или к чему ? Как только ваши вопросы начнут относится к объектам, а не к рсубд вот и и будет ОРМ.

ОРМ - это процесс, технология, если для реляционой бд есть формулировки типа нормальных форм, то для объектных бд такие "формы" еще в поиске и теоритеческом и практическом.
Отсюда и вся путнаица и холивары.

 

[Тугай]

Т.е. если я использую основные операции с базой нет смысла в использовании ORM?

Програмиррование - творческий процесс или как когда-то говрорили искусство, хотя его все больше попыток сделать его технологичным.
На это вопрос нет ответа, на самом деле, вы же не киркой в шахте собрались махать ? Из чего делать скрипку из яблони или из груши или из ... или из волшебного дерва ?
Не надо в ступор впадать с модными технологиями, орм, фреймфорками и прочим - все равно прийдется писать код, супер шуроповертом не выдернешь и не забьешь гвоздь, каким бы техно он не казался, не надо забывать про простой молоток и гвоздодерг.

 

[WMix]

Тугай молодой видать, каждый мотоцикл изобретать с нуля. правильно, нафига магазин напротив, мы сами крылья из жести ножницами вырежем!

 

[ваяс]

phpclub
И его участники, как всегда в своём репертуаре.

Програмиррование - творческий процесс или как когда-то говрорили искусство, хотя его все больше попыток сделать его технологичным. все равно прийдется писать код

Так можно сказать и художнику, всё равно придётся писать картину.
Закройте пожалуйста уже бессмысленную тему.

 

[keltanas]

С.
Выбор есть. Например http://design-pattern.ru/patterns/table-data-gateway.html

ваяс
Главная мысль в том, что используя ООП ты манипулируешь объектами, а не данными. Если это так, то тебе нужна ORM, т.к. ее задача сохранять объекты в базу и доставать их оттуда.
Если у тебя нет модели в принципе и всю логику и запросы пишешь в контроллере/представлении (или может это одно и тоже?), то ORM тебе не нужна. До тех пор, пока не начнешь использовать MVC и ООП.

 

[С.]

Выбор есть. Например http://design-pattern.ru/patterns/table-data-gateway.html

Это ORM.

 

[Тугай]

phpclub
И его участники, как всегда в своём репертуаре.

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

Надо наверно пример на PHP. С использованием ORM код в контроллере может быть таким:

$product = new Product;
$product->find($request->id)->current();
$this->view->price = $product->price;

Тут нет SQL, но есть запрос к нашей модели (виртуальной объектной базе) $product->find().
Преимущества простые, SQL запросы пишуться один раз и прячуться за методы нашей модели (или язык запросов).
Такие запросы легко повторно использовать.

 

[ваяс]

Тугай
Тема совсем другая, или я тут никого не понимаю.
Я знаю как это выглядит, я всего лишь хотел послушать мнения людей, но не поучительные советы.
Хотя спасибо и за советы. Только дурак не поменяет своего мнения.
Но мне правда не понятны вот эти вещи
Чем вот это

ORM->get('users')->where('pipirka') и т.д.

Удобнее вот этого

SELECT * FROM users и т.д.

Возможно ответ кроется в том же самом, как и спросить чем ООП удобнее функционального программирования.

 

[WMix]

sql хороший язык, и его удобно использовать в скрипте. но когда на руках переменные типа обьекта, то проще считывать так
$rows = $users->fetchAll():
а записать так
$user->update(); // ->insert()...
и не мучаться вытаскиванием аттрибутов или наоборот раскладкой по запросу

ORM->get('users')->where('pipirka') и т.д.

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

$sql = $db->select()
....
$sql->where(...)
...
$sql->joinLeft(...)->group(...)->where(...)

то можно творить чудеса