Хз, в таком случае меньше понимания структуры БД, запросов, меньше очевидности по крайней мере для меня

А вы попробуйте.

Пока не попробуете - очевидности не прибавится.

За дискуссию спасибо:) Подниму, пожалуй, ещё одну холиварную тему:) Я создаю много сайтов на Perl, и никогда не использовал фреймворки. Структура моего стандартного веб-приложения выглядит так: Apache+FCGI, NGINX кэширует на фронте, сзади Perl скрипты на FCGI с базами данных и другим софтом. И опять же, всё работает мега-быстро, в том числе на высоконагруженных сайтах. Возникает похожий вопрос, зачем мне Dancer/Mojo/Catalyst?

Модель данных на то и нужна чтоб отделить ее конкретное устройство от остального кода. Те кто пишут на dbi все равно обычно создают классы враперры ч которых разные методы выполняют определенные запросы и хранят ответы. Это уже простая но модель данных. Dbix::class предоставляет готовую модель которую можно гибко расширять. Хз как еще обьяснить

Можно и ооп не юзать, писать на функциях. Можно вообще не юзать перл и писать на сях или на асемблере сразу.

Дело вкуса

Можно и в космос полететь, если очень захотеть:)

Во, вот это я могу принять за аргумент!

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

Спасибо, я понял вас! Для моих личных проектов проблем никаких нет - делаю, что хочу, а вот заказчики хотят DBIC и Mojo какой-нибудь, и имхо, проблема в том, что эту "моду" им тоже кто-то навязывает

Не злитесь, но по статистике собеседований (конечно же, субьективной), люди которые пишут без фреймворков, аля cgi/dbi, обладают в среднем гораздо меньшими познаниями как самого языка так и подходов программирования. Отрицание использования фреймворков часто бывает изза нежелания или невозможностью разобраться с идеями более современных подходов к архитектурам. Типа «я писал так 10 лет и все было ок». Если разобраться и научиться этим пользоваться то выясняется что можно писать лучше.

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

Каталист / Mojo / Dancer - это комбайны. Все в одном. Кто-то работает быстрее, кто-то - медленнее. Кто-то может больше и т.д. Как и у любого комбайна они дают архитектуру и требуют ей следовать (не следование этой архитектуре возможно, но заставит больше писать). То есть это известный механизм у которого довольно большое количество неизвестных определено (то есть есть ответ на вопрос "Как сделать Х"). Больше чем в FCGI + Apache.

Кстати... Высоконагруженные - это сколько RPS / RPD?

Проблема производительности в catalyst и dbix::class например давно известна, но это не проблема подхода а проблема конкретной херовой реализации. Поэтому лично я считаю каталист гавнищем.

Ну мы тут больше о концепции, чем о конкретных реализациях ))

Ну человек упомянул что у него быстро работает)) щас начнет каталист тестить и скажет что ваши эти фреймворки гавно и медленные

Отчасти вы правы, я не вписываюсь в современный портрет нужного на рынке Perl специалиста, но есть и обратная сторона медали - мой код на DBI и FCGI прекрасно и быстро работает, он более читабельный (ну, по крайней мере для меня), я глубже понимаю MySQL, чем среднестатистический программист Perl, который использует DBIC. Т. е. я о том, что на самом деле я, со своим "устаревшим" подходом понимаю больше и   глубже в разработке ПО, но на рынке труда мне отведено менее сытное место, скажем так:)

Это еще вопрос что значит быстро... А то сейчас окажется что быстро - это 100 запросов в секунду.

Использование dbic никак не отменяет необходимости знания sql и баз данных, как я уже писал это просто модель данных а не волшебная палочка

На одной YAPC создатель DBIC рассказывал обратное, приводил это как преимущество