<HTML><BODY>В моём варианте можно унаследовать класс DBC::User и сделать то же самое. <br><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;"><div id=""><div class="js-helper js-readmsg-msg"><div><div id="style_14213533480000000974_BODY">
Пользовался подобным несколько раз, но, в основном, "всё иначе" и объекты БД <br>
не привожу к ООП (смеси данных из БД и произвольных методов), а определяю <br>
отдельный API работы с ядром, а что вернёт хендлер метода API уже дело <br>
хендлера.</div></div></div></div></blockquote>Согласен, неудачный пример. Ну да, надеюсь простите, если не буду более удачного показывать... Под рукой ничего такого не находится с ходу. Хотя-я-я... Да вот пожалуйста: поле active_status - является-ли пользователь активным или нет. Раньше было поле, которое должно было апдейтиться по крону и на его основе перебирались таблички на быструю и медленную (для Пг это разумно, чтобы больше вероятность попадания была). Рассчитывали запилить такой подход, потом оказалось что понятие активности для бизнеса и для базы - разные вещи. active_status стал геттером, который проверяет конфиг и last_visit. Приложения (которых много и разрабатываются несколькими командами) не заметили этого и продолжили жить, как есть. Таких примеров... не то, чтобы много, но они есть. Это конечно, не панацея, но в некоторых случаях помогает.<br><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;"><div id=""><div class="js-helper js-readmsg-msg"><div><div id="style_14213533480000000974_BODY">Ни разу не наблюдал особой проблемы с количеством модулей. Ах, да, я ж, <br>
наверное, "не писал сложных проекто никогда". Возможно.<br></div></div></div></div></blockquote>Хватит прибедняться... Я вот тут недавно заметил, что на текущей архитектуре мне надо создать 4 или 5 файлов, чтобы реализовать ту или иную фичу... Сейчас с этим боремся.<br><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;"><div id=""><div class="js-helper js-readmsg-msg"><div><div id="style_14213533480000000974_BODY">Да ничем, кроме некоторой негибкости кода, по моему мнению.</div></div></div></div></blockquote>Первое что приходит в голову - вы теряете возможность кастомных типов данных. Допустим у нас есть специальный тип, который сериализуется в JSON. В схеме я ему пишу тип: MyCoolSpecialType, а во время создания объекта прописываю inflate и deflate процедуры. После чего ...->single->cool_column->make_cool_method_on_my_cool_type. Наверняка еще 100500 маленьких приятностей, которые называются сахаром.<br><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;"><div id=""><div class="js-helper js-readmsg-msg"><div><div id="style_14213533480000000974_BODY">Ой. И никакой ORM? <br></div></div></div></div></blockquote>Подколка засчитана... Свой ORM из 15-20 строчек не считая сервисной рутины.<br><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;"><div id=""><div class="js-helper js-readmsg-msg"><div><div id="style_14213533480000000974_BODY"><br>
> В SQL::Abstract думали еще и о том, что это должно<br>
> выполняться на как можно большем количестве диалектов, допустим.<br><br>
Ну да, поэтому работу с offset/limit решили не делать. SQL::Abstract. как ни <br>
странно, ничего не хочет знать про БД, он именно абстрактный "вычислитель <br>
запросов".</div></div></div></div></blockquote>SQL::Abstract::More , если вам надо больше. ))<br><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;"><div id=""><div class="js-helper js-readmsg-msg"><div><div id="style_14213533480000000974_BODY">Зависит от ситуации. Хранимки выполняют две функции: поддержание некоторого <br>
API БД и исключение лишнего трафика клиент-сервер. Если сам запрос достаточно <br>
тяжёлый и лишнего трафика сервер-клиент нет, то хранимка особого выигрыша в <br>
производительности не даст, но некоторые алгоритмы там всё-таки разумнее <br>
реализовывать. Но, собственно, кому я рассказываю.<br></div></div></div></div></blockquote>У нас философия такая:<br>Все что надо сделать с базой, чтобы база работала быстрее - делается внутри базы... То есть теоретически можно и RULE на VIEW навесить и сказать что это таблица и прочее. Но только до тех пор, пока это надо и потому что по другому никак, но надо. Остальное - в приложении.<br><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;"><div id=""><div class="js-helper js-readmsg-msg"><div><div id="style_14213533480000000974_BODY">Нет, так как раз запутаннее. Сначала надо всё-таки полную структуру <br>
подразумеваемого приложения понять. Фронт запрашивает ядро. Ядро обращается к <br>
бекенду. Бекенд обращается к базе. При этом объекты ORM выступают в роли <br>
бекенда (или ядра?). Я запутался.</div></div></div></div></blockquote>Front-end(браузер) запрашивает страницу, nginx через proxy-pass отдает запрос на один из back-end'ов, которое есть наше приложение. Ядро - это набор библиотек, подключенных туда-же.<br><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;"><div id=""><div class="js-helper js-readmsg-msg"><div><div id="style_14213533480000000974_BODY">Я признаюсь, ни разу не писал, когда бекендов много. Или когда баз данных <br>
много. У меня были проекты, когда несколько фронтов<->ядро+база, а проблема <br>
производительности базы решалась ростом RAM и переходом на SSD. Но, я <br>
чувствую, что это просто мелочь в сравнении с настоящим хайлоадом.<br></div></div></div></div></blockquote>Не совсем... Просто настоящий, как вы говорите, хайлоад начинается тогда, когда больше RAM и больше SSD не дают эффекта или не выгодны, так как нагрузка может кратно превысить сервер... Тут есть несколько вариантов, они, в общем-то, описаны в интернете (но по задворками и равномерным слоем) и никакого ноу-хау там нету. Просто подходы меняются и все.<br><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;"><div id=""><div class="js-helper js-readmsg-msg"><div><div id="style_14213533480000000974_BODY"><br>
> Посмотрите в сторону DBIx::Simple в связке с SQL::Abstract я думаю вас это<br>
> удовлетворит, так как это оно и есть.<br><br>
Смотрел когда-то давно. Ну, допустим, я повторил даже чью-то функциональность. <br>
Но, как мне кажется, я сделал это удобнее. И зачем мне отказываться от того, <br>
что я написал в пользу других модулей? Например, в моём модуле есть следующий <br>
сахар (цитата из документации)<br><br>
Допустим, у нас есть следующие таблицы:<br><br>
employer:<br>
id_employer,<br>
name<br><br>
employee:<br>
id_employee,<br>
id_employer references employer (id_employer),<br>
id_employee_invited_by<br>
name<br><br>
alter table employee add constraint fk_employee_employee <br>
foreign key (id_employee_invited_by) references employee (id_employee);<br><br>
Тогда можно использовать следующие выражения:<br><br>
my $employee = one_row("employee", {name => 'John'});<br>
my $employer = $employee->Employer;<br><br>
Последняя строка автоматически по ссылке из объекта $employee выберет объект <br>
$employer.<br><br>
my $referenced_by = $employee->refEmployeeInvitedBys;<br><br>
Эта строка выберет всех "employee", которые были рекомндованы конкретным <br>
$employee.<br><br>
my $robert_associates = $employee->Employer->refEmployees(name => 'Robert');<br><br>
А эта строка выберет коллег этого $employee, у кого имя 'Robert'.<br><br>
Личто мне этот сахар удобен и экономит код. На счёт эффективности не вижу тут <br>
проблем так же.</div></div></div></div></blockquote>refEmployeeInvitedBys и refEmployees из коробки в том-же DBIx::Class'е нету, но... Как вы не видите, что пишете свой DBIx::Class, который в последствии разрастется хуже оригинального?.. Если видите, так может сразу взять лучшее оттуда и добавить недостающие фишки... Причем DBIx::Class тот-же прекрасно сабклассится (если понимать идеологию mro::c3)<br><br>Ну хорошо... вы хотели некоторых отзывов...<br>Открываем DBIx::Struct.pm:<br>%driver_pk_insert - и там код как строка... Зачем?..<br>Идем дальше...<br><span class="pl-st">sub</span> <span class="pl-en">make_object_new - Бешеная кодогенерация</span>. Вы про наследование слышали? Делаете класс-аксессоры, а потом тупо:<br><br>sub create_new_package {<br> my ($self, $class_name, $config) = @_;<br> my $isa = \@{"${class_name}::ISA"};<br> push(@$isa, "DBIx::Struct::Base");<br> $class_name->_initialize($config); # Или не делаете, если инициализировать нечего или сами забивайте руками эти аксессоры.<br>}<br><br>Нет, все... Я на куче кодогенерации выпал в осадок.<br></BODY></HTML>