Часто ли вы прогибаетесь под логику, которую диктует вам фреймворк?

[Фанат]

У меня тут коллега недавно, ни с того ни с сего, забабахал вьюху в базе.
Причем раньше они у нас никогда не использовались.
Я полез посмотреть и обнаружил, что весь балет затевался ради простоты использования данных в ОРМ-е - структура данных и логика выборки получились достаточно сложными, даже квери-билдером у меня написать не получилось, а орму и подавно не по зубам.

Столкнулся я с этим запросом из-за его адовой неоптимальности.
В итоге выкинул вьюху, написал нормальный запрос, всунул его в модель отдельным методом и для контроллера уже ничего практически не изменилось. при этом девелопмент воркфлоу вернулся в обычное русло - данные в базе, логика в моделе.

Такая вот сказка про то, как ОРМ выдавил логику в базу.
Мне это не нравится. Если вы используете вью как правило - ради бога.
Но вот прогибаться под орм мне не хочется.

Я неправ?

 

[DIG]

Я любитель-самоучка, поэтому позволяю себе такое. Т.к. часто берусь доделывать проэкты с уже готовой структурой базы данных и мне никто не доплатит если я сяду разрабатывать нормальную структуру этой базы. А вьюхи в таких случаях спасают. Но с другой стороны если в таком курятнике (ОРМ+вьюхи) нужно чтото поменять через пару месяцев - приходится неделю разбираться. В общем я считаю что так делать нельзя, но если очень хочется...

 

[флоппик]

Такая вот сказка про то, как ОРМ выдавил логику в базу.

WAT ?
Ага, кухонные ножи провоцируют на бытовые убийства.
Ты по-моему уже заклинился на борьбе "голый скуэль лучше орм" что начинаешь прогибать логику здравого смысла под свои аргументы.
Если разработчик обделен интеллектом - инструмент не виноват.

 

[Фанат]

Ты по-моему уже заклинился

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

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

 

[AmdY]

Пример демонстрирует отличие acrive records от orm, в вашем случае был ar

// вот обычный qb
$q = new Doctrine_RawSql();
$q->select('{u.*}, {p.*}');
$q->from('user u LEFT JOIN phonenumber p ON u.id = p.user_id');
// а вот начинается ORM
$q->addComponent('u', 'User u');
$q->addComponent('p', 'u.Phonenumbers p');

 

[флоппик]

AmdY, то что сделал Фанат - это все равно object relational mapping.

 

[AmdY]

Я бы кстати, юзал таки фреймворк, даже вьюхи не люблю, а вот сложные запросы на дух не переношу, мы как-то посовокуплялись с запросами ibm dba, новая фича превращалась в ад с рекурсивными запросами, которые даже фиг протестишь,а мы то простые пых разработчики, не задрачивались годами с db2 и oracle.

Я последние годы подзабил на слова - правильно, лучше и т.д., делаю как надо, главное чтобы работало, если надо даже html в контроллере сгенерю, главное делать всё вовремя и без гемороя и всегда есть рефакторинг. Вон Григорий предлагает холивар о собаках, а я лучше шашлык в этот момент буду есть.

 

[Redjik]

Фанат, по сути недавно сделал тоже самое, только немного дальше пошел.
Уже не раз сталкивался с ситуацией, когда AR не справляется и это нормально.
Опять же все хотят во вьюхе видеть обьект модели (хотя я бы массив с данными кидал ).

Поэтому (только в рамках yii и с большими ограничениями) написал парсер данных с базы в модель.
Процесс примерно так выглядит.

       //пишем селекты
        $userSelect = new Select('u',['name','email']);
        $phoneSelect = new Select('p',['phone']);
       
        //получаем данные
        $records = $db->createCommand(
            'SELECT '.BuilderHelper::buildSelectString([$userSelect,$phoneSelect].'
            FROM users as u LEFT JOIN phone as p ON (...)
            ')
        )->queryAll();
       
        //создаем парвила парсинга
        $rule = new SimpleRule('Flat',$userSelect);
        $rule->addRule(new SimpleRule('Phone',$phoneSelect),'phone');
       
        //парсим
        $arObjects = [];
        foreach ($records as $record)
        {
            $arObjects = $rule->interpret($record);
        }

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

 

[Redjik]

И да, вроде бы ненужный велосипед, но когда нужно сделать поиск по 5-6 атрибутам EAV и при этом вывести их в результат - любой ORM, любая AR курят в сторонке.

 

[флоппик]

Окей, я попробую еще раз.
Я понимаю, что профессиональная терминология не в чести у пхп разработчиков, которые упорно пытаются придумать свое определение интерфейса и все такое, но:
То, что сделал Фанат - это ORM(object relational mapping) и есть - проекция реляционных данных на объект. То, что ему на самом деле не нравится - это скорее всего, конкретная реализация Active Record (по сути своей придуманная для дешевого CRUD, а не для сложных данных) в одном каком-то конкретном фреймворке. И это все было бы ок, если бы не: 1. Утверждение, что фреймворк снимает отвественность за кривые архитектурные решения с разработчика (Don't blame the tool, и все такое). 2. Утверждение, что "вьюхи" в базе - это что-то особенное с точки зрения логики (не все базы данных похожи на инвалида мускуля, да, я понимаю, это пхп, и все такое). 3. Ну вы знаете, богоданных суперплейсхолдеров должно быть достаточно каждому.

 

[Фанат]

Я бы кстати, юзал таки фреймворк, даже вьюхи не люблю, а вот сложные запросы на дух не переношу.

А что вместо-то?
Не, я понимаю что понимание "сложности" у всех разное, но как другим способом получить нужные данные?

А вообще вопрос был не про это. А про то, что орм, на мой взгляд, зачастую диктует не самое оптимальное с точки зрения архитектуры решение. И буратинский мачизм -

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

- здесь не очень-то к месту. Если оно "лишь бы работает" на продакшене - это ок. Если на деве, а на продакшене валится под нагрузкой - как-то все-таки проектировать желательно, ДО начала разработки.

 

[AmdY]

А что вместо-то?

простые запросы и кэш

Фанат, ORM ничего не диктует, оно лишь биндит обычный результат запроса на объекты. Причём для php это работает из коробки, так как mysql_fetch_assoc уже мэппит даннные на удобный ассоциативный массив, экс сишники очень любят использовать индексы 0..1.

Слушай, ты можешь для своей обёртки над базой написать мэппер, которому будешь оттавать ему результат и правила какие данные на что биндить. В итоге ничего не меняется, запросы остаются теми же, разве что для удобства добавишь префиксы.

 

[Фанат]

простые запросы и кэш

понятно

 

[hell0w0rd]

простые запросы и кэш

А почему вместо этого не использовать бы вьюху?
Мне нравится фраза Фаната - база создана, чтобы из нее получать данные, зачем изобретать велосипед в виде кеша, там где это не совсем нужно?

Другое дело, что я не видел ОРМ, которая вьюхи поддерживает на уровне описания схемы

 

[AmdY]

hell0w0rd, для баз данных использую только инструменты, которые поддерживаются нормально со стороны php. Всё через миграции и ORM, иначе потом проблемы с деплоем и девелоперским воркфлоу. Ясное дело, без фанатизма, пока это не мешает пить пиво. Вот именно база данных - это инструмент и я стараюсь с ним не разбираться, пока он работает, а не разбираться во 100500 видах джойнов, вьюхах, триггерах, рекурсивных запросах. Тем более я работаю не один и масса колег, которые знаю сильно меньше, а то и джуниоры. В этом плане я ненавижу гит, он позволяет 100500 способами решить проблему, которые в нормальных VCS быть не должны, а ещё нужно заучивать сотни команд и ключиков.

 

[hell0w0rd]

AmdY, по поводу нормальной поддержи со стороны php полностью согласен. Однако база данных такой же инструмент, как и php, почему бы с ним не разобраться? Для меня инструмент в таком понимании - отправка почты. Вот тут действительно не важно, как там smtp работает, письма отправляются - и хорошо. Но базу к таким вещам ну никак отнести нельзя
А что не так с гитом? все не тривиальные команды можно засунуть в баш-скрипты/алиасы.

 

[keltanas]

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

ORM-то - она ничего не диктует. Во всяком случае, как паттерн по Фаулеру.
В описанном примере коллега сам должен был сделать так же: не городить вьюху, а написать метод "ручного" получения сложной выборки и её маппинга на доменные объекты.
Другое дело, что он решил воспользоваться средствами автоматического маппинга, чтобы облегчить себе жизнь. Но это, скорее, не прогибание под логику ORM, а типичная лень, которой многие, в общем-то, грешат

 

[confguru]

По своему опыту - ORM - идеальна для справочников до 1000-5000 записей.. Если данных больше пишите свои методы доступа.
А танцевать над от того - что на страничке ты можешь показать только <=1 мб данных и не стоить гонять гигабайты в php - от этого мутит
Хороший подход всегда смотреть сколько памяти потребляет тот или иной скрипт..

 

[Absinthe]

Фанат, Хотелось бы конкретики. Что за ORM?

Если данных больше пишите свои методы доступа.

scope?

 

[Фанат]

Фанат, Хотелось бы конкретики. Что за ORM?

Фуйло.
Но орм, по-моему, это такая штука, для которой фамилия совершенно не важна.