Когда использовать ORM фреймворки?

caballero

Новичок
А потому, что она вредная и не работает в 99,99% случаев обсуждений на этом форуме.
решение либо верное либо нет. И от количества обсуждений на форуме не зависит

И написание километрового SQL пусть скрытого за вьюхой в случае сильного PHP инструментария обернется одной-двумя строчками связи. Все.
Полная фигня. То что нужно выбрать километровым запросом никакой инструментарий не упростит, либо упростит за счет существенной потери производительности.

ORM - это общий принцип. Все реализации этот принцип реализуют. Хотите красоты и гибкости - DM. Что попроще - AR. Нужно ковырять сразу огромные объемы данных в таблице - TDG. И разве что DM создан, что бы убрать SQL из объектов, остальные это не запрещают, пишите SQL... это все-равно будет ORM.
ну если все начиная с PDO называть ORM тогда конечно. Но речь шла о движках типа Doctrine.
 

Adelf

Administrator
Команда форума
так что никаких противречий. Если ты тоже хотел возразить из политических соображений то мимо. Только в отличие от предыдущего оратора который просто чушь несет ты написал то чему собственно особых возражений (по теме использования представлений) и нет
Вас касался только последний абзац. Первые ваши ответы в данной теме явно проповедуют написание чистого SQL в коде без всяких прослоек. Исходя из того, что 95% операций в любой системе это стандартные CRUD - код приложения у вас будет полным неподдерживаемым мусором, с особо прекрасными представителями которого мне, к сожалению несколько раз уже приходилось встречаться.
 

caballero

Новичок
что 95% операций в любой системе это стандартные CRUD
даже в админках это далеко не 95 процентов - уже обсудалось на примере выборки репортов и страницы этого форума.

тема себя исчерпала
Напиште еще что нибудь бессмысленное или очевидное чтобы ваше слово осталось последним - будете тешить свое ЧСВ что разгромили врага
 

Redjik

Джедай-мастер
Не ребят - с nemo было смешно.
Вспомните только.
ОЛОЛО 11111ВЫ ТУПАЯ ШКОЛОТА - МНЕ НАПИСАЛ ДУРОВ

А тут - грустно как то все.
 

Adelf

Administrator
Команда форума
Иван Redjik Матвеев
Тут тоже прикольно. "Мне 150 лет. Вы все нифига ничего не знаете" :)

Upd: А в первой теме даже по моим родителям прошелся. Так что и элементы школоты тоже присутствуют.
 

varan

Б̈́̈̽ͮͣ̈Л̩̲̮̻̤̹͓ДͦЖ̯̙̭̥̑͆А͇̠̱͓͇̾ͨД͙͈̰̳͈͛ͅ
ну если все начиная с PDO называть ORM тогда конечно. Но речь шла о движках типа Doctrine.
ORM - это грубо говоря просто механизм связывания объектов модели с БД. Как именно будет сделана эта связь - с помощью чистых sql запросов или query builder а - дело десятое. Т.е. метод save() объекта User вполне может содержать в себе UPDATE user SET blablabla, и это тоже будет ORM.
Ваш К.О.
 

Redjik

Джедай-мастер
Adelf
Вот море молодых колышет супербасы, (про MVC)
Мне триста лет, я выполз из тьмы.
Они торчат под рейв, (про ORM)
и чем-то пудрят носы -- (про view)
Они не такие, как мы.
 

MiksIr

miksir@home:~$
Полная фигня. То что нужно выбрать километровым запросом никакой инструментарий не упростит, либо упростит за счет существенной потери производительности.
Полная фигня. Генерация связей делается легко и непринужденно и выливается в итоге в тот же самый километровый запрос. За исключением того, что программист может сделать его опциональным когда это реально нужно. А вьюхой уже так не поуправляешь. И за исключением того, что программист может одним флагом переключить джойн на два запроса для избежания оверхеда при выборках один ко многим. Так что повторюсь - не надо пинять на мир если собственные понятия слабы... почти К.Прутков.
 

AmdY

Пью пиво
Команда форума
caballero
а ты доктрину в глаза видел? там за счёт менеджера сейчас производительность только улучшилась, так как она не позволяет косячить по глупости и проводит мелкие оптимизации.
доктрина не мешает писать sql (dql) и затем его результаты мапить на модель. можно доктрину использовать как тупой AR для CRUD, можно писать свои template и получить мощную систему, можно даже вьюхи создавать и мепить модели на них.

Всё зависит от ваших use case-ов, а плохому танцору сами знаете что мешает.
 

baev

‹°°¬•
Команда форума
Просьба к участникам дискуссии воздержаться от нецензурных слов и выражений. (И цензурными словами оскорблять не надо тоже.)
Употребление площадной брани показывает ограниченность вашего словарного запаса.
В том числе, показывает, что вы — «не в теме», и тупо не можете выразить своё мнение в профессиональных терминах.
 

Raziel[SD]

untitled00
На тему использования ORM был неплохой топик 6 лет назад, и по моему с тех пор принципиально лучше не стало.

З.Ы. тут 6 страниц борьбы с троллем, топик свелся к личным разборкам :)
 

alekciy

Новичок
во первых такие классы придется создавать на каждую выборку на каждый репорт
varan под указанную задачу предложил вполне работоспособный подход. В чем проблема иметь класс внутри которого "чистый" SQL который решает конкретные задачи конкретного приложения? Если это плохо, то почему и какая альтернатива?
 

Deserved

Новичок
Вообщем почитал 6 страниц, но нужной информации, практичной не наблюдается по сути вообще на этих страницах.

В проекте встал вопрос использовать ли Доктрину, довольствоваться тем что предоставляет Zend Framework 2 либо колотить своего квазимоду. Много предрасудков, и вытянутых из пальца "фактов" было озвученно на митингах, но не одного плюса, либо разумного довода. Лично для себя в Доктрине открыл следущие плюсы:

1. Быстрая разработка: Имеешь модель, создал сущность, создал репозитарий (если угодно) и этим оградил Бизнесс логику от всяких заморочек с ДБ, а также не потратил время на воссоздание всяких абстракций для обработки результата.
2. В моём случае мы имеем БД по умолчанию, которая включает ключевые таблицы для работы продукта, каждый клиент может усовершенствовать таблицу под свои нужды (увеличить, но не уменьшить). Сдесь Доктрина делает своё без проблем. Выборка правельной сущности/репозитария может потом быть разрешена при помощи Фабрик.
3. Кэширование, можно кэшить анотация, Дикуэль, результат, метадаты при помощи разных драйверов. Дало 5 кратное ускорение.
4. Возможность использования как SQL так и DQL.
5. Lazy-loading не надо загружать все ассоциации сразу.
6. Имплементацию спрятать в Репозитарию, а там как хошь так и колдуй. Хоть DQL, хоть SQL, хоть в файл записывай. Вообще через репозитарии можно много что решить. Мануал в помощь :)
7. и т.д. и т.п.

Но хотелось бы услышать как, кто использовал Доктрину в высоконагруженных проектах, какие проблемы были? При какой нагрузки возникали?
 

Raziel[SD]

untitled00
Но хотелось бы услышать как, кто использовал Доктрину в высоконагруженных проектах, какие проблемы были? При какой нагрузки возникали?
Если смотреть с этой стороны, тогда вопрос: какие средства для масштабирования БД есть в доктрине ? или что ты планируешь делать, когда БД на 1 сервере перестанет справляться с нагрузкой ?
 

С.

Продвинутый новичок
Нет и не будет "серебряной пули". Мастерство разработчика и определется умением подобрать наиболее эффективное решение для данного конкретного случая в данных конкретных условиях.
 

Фанат

oncle terrible
Команда форума
3. Кэширование, можно кэшить анотация, Дикуэль, результат, метадаты при помощи разных драйверов. Дало 5 кратное ускорение.
запросы оптимизировать не пробовал?
 

AmdY

Пью пиво
Команда форума
Deserved
из всех ваших пунктов ни в одном не было ничего о том. чтобы использовать преимущества объектов. так что вам без разницы что использовать.

orm и доктрина это прожде всего объекты, а значит разные мутаторы и аццесоры для доступа к данным, это дополнительная логика при CRUD в теперешней доктрине это фильтры и подписка на евенты, это расширение сущностей, это использование методанных для кодогенерации, это умное размазывание по серверам, эти атамарность и Identity Map, это кастомные типы полей и т.д.

для быстрой разработки вам больше подойдёт простой active record. у доктрины есть куча своих граблей о которые постоянно будете спотыкаться. доктрину следует использовать когда вам действительно нужно орм, а не абстракция над базой данных или если используете симфони. Вот ZF2 это первое от чего нужно избавляться, если из той же категории, то лучше Symfony, если из дургих то Yii, Laravel etc.
 
Сверху