builder'ы позволяют разбить создание запроса на несколько функций. Например, у меня все запросы создаются (build) в моделях, а в вызывающем коде:
m('user')->select(
['deleted' => FALSE,
'has_login_role' => TRUE,
'select_n_images' => TRUE,
...
'offset' => ...,
'limit' => ...,
'order by' => ...]);
ORM мне самому не нравятся. Обычно через непродолжительное время наступает момент "извините, но в данной ORM это не возможно". И код у них обычно сложный. Единственный "завершенный" вариант, который я видел - Entity Framework (MS). Но он статический, а мне это как минимум непривычно.
Абстракция от БД - миф. При переходе на другую БД в любом случае надо будет просмотреть все запросы. Если ты не используешь Entity Framework.
|
Сообщение от Gozar
|
|
Такие реализации только добавляют ненужные тормоза в программу.
|
Тебе не нужен ORM/builder'ы или ты так думаешь. Зачем приплетать к этому какие-то тормоза? Я в свою очередь мог бы сказать: "Мой ООП код так же тормозит как твой процедурный код". Не важно, что при 1000000 тысячах итераций ООП-страничка отобразится медленнее, чем процедурная страничка. Важен компромисс между удобством разработки, скоростью разработки и производительностью. Ведь цель - создать сайт, а не абстрактно ускорить сайт, м? Но можем попробовать написать небольшой сайт, ты на своем фреймворке, я на kohana. Сравним... В прицнипе есть еще php fat-free framework, но тогда скорее всего в моем коде будет недостаточно ООП.
По поводу документации, в kohana ее наверное не очень много. Хотя сейчас наверное документации больше. Они по этому поводу сильно не парятся. Говорят, что чтобы использовать kohana нужно быть готовым заглядывать в исходный код. Код хороший и с комментариями. У меня проблем не было. И мне нравится эта позиция - отсеивает лишних кандидатов. Либо с другой стороны, учит нужных кандидатов.