Здравствуйте. Недавно сел за большой проект, хочу писать с самого начала хорошо. В проекте использую паттерн MVC, но с БД работаю как обычно: PDO + запросы написанные руками. Недавно прочитал о том, что можно представлять таблицы БД в виде объектов(http://www.gamedev.ru/pages/php_height_load/articles/?id=5140), в Java, кстати, используется похожая концепция(только там сущности). Стоит ли для каждой таблицы писать свой класс или лучше самому писать запрос в нужном месте(через PDO, конечно).
то что ты хочешь называется ORM и есть готовые решения типа propel, doctrine ... но можно и свое запилить
+ удобство: чище код, быстрее писать, удобнее вертеть, связи, логирование / события и прочее. - скорость работы, память. Как правило не заметно, но если запросы считаются сотнями-тысячами (какая-нибудь хитрая обработка), то ресурсы потекут рекой )
Ну, к примеру в стандартном ларковском eloquent я прописываю связи, куски запроса, которые можно легко подтянуть к текущему, доп.атрибуты и потом вообще не думаю о sql, гуляя по связям, фильтруя и кастуя хитрую магию. Но конечно при этом необходимо понимать в какие запросы к БД всё это преобразуется, дабы не выстрелить себе в ногу )
У меня не меняются так запросы. Я если один раз написал, то годами запрос не меняется. Какой смысл иметь хитрый инструмент, если гибче текста для таких дел нет ничего априори?
К примеру, если мне нужно получить все заказы пользователя, я просто пишу $user->orders и там будет коллекция со всеми его заказами, а по $order->items - товары из которых он состоит. Благодаря прописанным в модели связям ORM сама скастует нужные запросы. Более того, я могу ещё и дополнительные условия добавить прямо на месте или даже не на месте, а передав объект куда-нибудь, не путаясь потом в правильной последовательности сборки текстового запроса. Если мне нужно добавить к заказу товар, я делаю $order->save($item) и оно само воткнет нужные id. А теперь представим, что внезапно понадобилось при создании заказа отправить пару писем (клиенту и его манагеру) - я просто беру и вешаю действие на событие. Ну или к примеру, при конвертации в json могу сразу преобразовать idшники от справочников в их реальные значения, убрать лишние поля, добавить ещё что-нибудь, дабы не заморачиваться на фронте. При чем это не означает, что модель в результате распухнет до невероятных размеров и будет делать то, что к ней вообще не относится, всё это можно растасовать по нужным местам и подключать по необходимости. Короче, больше абстракция для бога абстракций )
До тех пор, пока ПХП будет работать от запроса до запроса, эти ваши ОРМы будут не более чем оверхедом по времени и памяти, не дающими никакого преимущества перед банальными ассоциативными массивами, возвращаемыми по умолчанию.
Я даже за вечер-другой могу накать простенькую ORM с подобным функционалом с нуля. Но зачем? Добавлено спустя 29 секунд: Пых таки уже может это делать. Только, опять же, зачем?
ну блин. А как ты программы пишешь, если ты в запросе путаешься? Добавлено спустя 52 секунды: ОРМ тут не при чем. Складывать методы куда надо и вешаться там можно и нужно в любом случае и без ОРМ. Добавлено спустя 49 секунд: Не понял о чем ты, расскажи плс.
Да легко. У тебя есть форма фильрации, в ней 10-15-20 параметров, что-то селект, что-то галочка, иногда это поле в той же таблице, иногда в связанной. Фильтры могут добавляться, могут исчезать. А может вообще появиться какая-нибудь хитрая выборка / сортировка со стороны. В какой момент времени ты запутаешься в мешанине условий, особенно если они собираются не в одном месте, а могут навешиваться по ходу дела? Вот у тебя есть обертка над mysqli/pdo в которую ты передаешь текстовые запросы, а она там делает подстановки и разбирает результаты, ты её дергаешь в нужных местах, вставляешь-удаляешь-выбираешь. Всё нормально. Теперь тебе нужно реагировать на определенное изменение в определенной таблице. Саму модель менять нельзя, т.к. седня компонент которому нужна эта фича есть, а завтра его уже нет, соотв. куча правок по коду тоже исключена. Как будешь его ловить? Фишка в том, что в результате ты либо пишешь свою реализацию всего этого функционала, либо используешь готовую, либо подпираешь код костылями ) Так почему бы сразу не воспользоваться готовым инструментом и не заложить нормальную архитектуру? хех, это вообще отдельная тема ) p.s я не говорю о случаях, когда весь функционал умещается в "вот пост, вот категория к нему, вот пара тегов", тут достаточно пары запросов вручную. Ну или когда тебе нужно разом ковырнуть лям-другой записей в БД, тогда пых падает под тяжестью ООП.
я не вижу разницы. Ты что так что эдак должен на каком-то языке написать этот запрос. Ты либо на языке ОРМ его пишешь, либо текстом. Какая разница? Где тут можно запутаться? Это просто перенос сущностей куда по-дальше. Ты сегодня делаешь этот код для этой задачи там, где ты его пишешь. Завтра он будет не нужен, и тебе всё равно его нужно будет откуда-то убрать или убрать весь код, который это делает. Это раз. Два. Изменение в таблице только тогда изменение, когда она изменилась. Три. Если ты меняешь бд, и тебе надо поменять данные где-то в твоём объекте, то не надо делать это гоняя эти данные в БД и удостоверившись, что они записаны, менять в данных, которые ты до этого выбрал и только тогда выводить на экран... В любом случае более правильно будет выбрать все данные и перерисовать всё заново, а если это не требуется, то видимо просто вернуть "ОК", т.к. на клиенте эти данные всё равно уже есть - они же с него пришли. Это какая-то запутанная ситуация, которую я просто решаю иначе, и потому мне не нужна ОРМ видимо. Мне чета кажется, что у меня нормальная архитектура. Пришли данные, ты их записал в БД, вернул "ок". Конец. Или. Пришел запрос, ты выбрал данные и отдал. Конец. Это в принципе не должно касаться пыха, сколько ты там данных ворошишь. Именно это меня в концепции ОРМ и отталкивает.
У мну смутное подозрение, что мы говорим о разных вещах, но при этом называем их одними словами ) Пример не абстрактный. У тебя есть модель заказов, они могут появляться и удаляться, у них может меняться статус выполнения, оплаты, доставки и прочее. По сути это и есть события, которые тебе нужно отловить. Не изменение в БД, а изменение согласно бизнес-логики. Да и список событий тем не ограничивается, может быть регистрация покупателей, тикет в службу поддержки и много чего ещё. Потому это не перенос сущностей, а разные сущности. Тебе нужно на уже реально работающий функционал навесить обработку этих событий в виде уведомления заинтересованных лиц. Врезаться в работающий код нельзя - ибо нефиг трогать, что и так работает, к тому же не в своей зоне ответственности. Дык вот, как ты на основе текстовых запросов поймешь что меняется именно сущность заказов и не просто она, а скажем статус доставки? Добавлено спустя 1 минуту 57 секунд: Разница в том, что к примеру, на основе объекта запроса ты можешь выстроить целую цепочку его дополнений / изменений, расширять её или наоборот, убирать лишние звенья, не затрагивая всего остального кода ) Добавлено спустя 1 минуту 12 секунд: Это очень даже касается пыха. На большем объеме данных / количестве итераций сборщик мусора говорит всем пока и сваливает )
Так и нормальная ORM это не SQL с ООП-синтаксисом. Потому мы друг друга видимо и не понимаем, т.к. я говорю про слой абстракции над данными, а ты о query builder )