-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Когда использовать ORM фреймворки?
- Автор темы G-SHEFF
- Дата начала
caballero
Новичок
Ни в каких. Лишний промежуточный слой кода и весьма громоздкий.
PHP каждый раз выполняет код страницы. И какой смысл каждый раз создавать гроздь объектов (да еще и парсить маппинг) чтобы они сформировали строку SQL которую быстрее написать вручную.
Опять же нет возможности использовать особенности БД. А если нужна переносимость между типами БД неплохо и ADODB справится (там и ActiveRecord есть если что)
PHP каждый раз выполняет код страницы. И какой смысл каждый раз создавать гроздь объектов (да еще и парсить маппинг) чтобы они сформировали строку SQL которую быстрее написать вручную.
Опять же нет возможности использовать особенности БД. А если нужна переносимость между типами БД неплохо и ADODB справится (там и ActiveRecord есть если что)
G-SHEFF
Новичок
для проекта плохо, для программера хорошо?
damner2
Новичок
типа того, но чем лучше умеешь работать с инструментом, тем более эффективен он будет для тебя.
Духовность™
Продвинутый новичок
caballero
иногда лучше жевать, чем говорить
G-SHEFF
ORM используется тогда, когда вы пишите ОО-код. когда у вас есть четкое понимание архитектуры, методов взаимодействия объектов и тогда ORM позволяет вам создать имитацию хранения объектов в БД, уйти от массивного представления данных и работать исключительно с объектами. Доктрина сложная, но идея ORM - благая и замечательная.
иногда лучше жевать, чем говорить
G-SHEFF
ORM используется тогда, когда вы пишите ОО-код. когда у вас есть четкое понимание архитектуры, методов взаимодействия объектов и тогда ORM позволяет вам создать имитацию хранения объектов в БД, уйти от массивного представления данных и работать исключительно с объектами. Доктрина сложная, но идея ORM - благая и замечательная.
Духовность™
Продвинутый новичок
caballero
иди нахер, а? научись разговаривать для начала. причем тут википедия? ничего я не цитирую. я работаю с проектом, использую ORM самописный. Для 90% операций с CRUD ORM подходит идеально, особенно для простых таблиц, для которых созданы модели (сущности). ОЧЕНЬ удобно. Код О-ориентированный. Все классно.
Ты сейчас опять тему загадишь холиваром. Успокойся. И ORM и другие методы имеют право на существование, не надо тут с пеной у рта доказывать что одно однозначно хорошо, а другое - однозначно плохо.
иди нахер, а? научись разговаривать для начала. причем тут википедия? ничего я не цитирую. я работаю с проектом, использую ORM самописный. Для 90% операций с CRUD ORM подходит идеально, особенно для простых таблиц, для которых созданы модели (сущности). ОЧЕНЬ удобно. Код О-ориентированный. Все классно.
Ты сейчас опять тему загадишь холиваром. Успокойся. И ORM и другие методы имеют право на существование, не надо тут с пеной у рта доказывать что одно однозначно хорошо, а другое - однозначно плохо.
caballero
Новичок
как раз для CRUD ORM нужен меньше всего
а если бы ты работал програмистом знал бы что три четверти запросов к базе в реальных проектах выходят за пределы работы с чистыми сущностями.
и уж тем более не относятся к CRUD. Или у тебя проект состоит из тупых гридов отмапленых на таблицы БД?
на ORM падки новички неумеющие писать SQL запросы.
Ragazzo
TDD interested
caballero
Большинство проектов состоит из гридов отмапенных на таблицы и чо? В 90% проектов нужно выводить какие-либо созданные CRUD сущности из таблиц, сортировать их и т д, и что с того? Если ты оперируешь слишком сложными запросами с кучей подзапросов, значит твой код полное нестабильное гавно, которое проще выбросить, и найти нормального программиста
Сложность приложения не всегда определяется сложностью БД, скорее говорит об обратном, что разработчик, который делал БД, не знает даже банальных нормальных форм и правил нормализации
Большинство проектов состоит из гридов отмапенных на таблицы и чо? В 90% проектов нужно выводить какие-либо созданные CRUD сущности из таблиц, сортировать их и т д, и что с того? Если ты оперируешь слишком сложными запросами с кучей подзапросов, значит твой код полное нестабильное гавно, которое проще выбросить, и найти нормального программиста
Сложность приложения не всегда определяется сложностью БД, скорее говорит об обратном, что разработчик, который делал БД, не знает даже банальных нормальных форм и правил нормализации caballero
Новичок
то что для тебя все что сложнее select * from слишком сложно - твои проблемы.
На то он и сервер БД чтобы выполнять сложные выборки оптимальнее чем делать стопицот линейных запросов.
Некоторые даже хранимые процедуры с бизнес-логикой пишут и как то проекты говном не выглядят.
как раз чем более нормализованая БД тем более сложные запросы нужны. В некоторых случаях даже приходится делать денормализацию для более эфективных выборок.
Пойди лучше выучи уроки на завтра чем писать о том о чем не имеешь представления.
