[Moscow.pm] v2 просьба о ревью модуля DBIx::Struct

[Warstone@list.ru]

 То есть сложных проектов, где есть "Ядро" и "Приложение", или гетерогенных, сервис-ориентированных приложений вы не писали? Хорошо... Вот вам пример из жизни...

Есть Ядро, в ядре есть определение пользователя. Таблицы пользователя. Как будет использоваться пользователь и какие у него будут дополнительные поля определяется приложением.  Ядро заботится о "стандартных" полях. У пользователя есть аватар. В модели есть аксессор для урла на аватар. Ядро, зная что серверов много и выбирая какие сервера сейчас активны, на каких из них есть этот аватар и т.д. отдает Урл аватара. Для Приложения это просто аксессор.

То что я описал - это один из примеров. Возможно не самый лучший. Но он дает представление о том, что ждут большие приложения от ORM'а. Если вы сможете поддержать ORM, когда я, написав сложный SQL запрос с аггрегатами и оконными процедурами в результате получив пользователя , получу урл на аватар, прогнанный через мой аксессор, не указывая что это пользователь (то есть ORM сам должен понять - откуда это взялось и что надо сделать с полями), то можно начинать разговаривать про ваш ORM. До этих пор большого смысла использовать его в "продакшене" я не вижу. Проблема в том, что я плохо представляю как этого добиться, не указывая очень много дополнительной информации при каждом запросе. Хотя вру... Для PostgreSQL - знаю как. Но только для него.

Теперь более детально:
> в реальном приложении, обычно, заранее известно 
что за база будет использоваться
Согласен. Хотя у нас используются сразу 2 СУБД: PostgreSQL и MySQL. Такой вариант немного сбивает с толку, правда?

> поэтому использование голого SQL вполне 
нормальное явление
Это не следует из вышенаписанного по причинам, изложенным выше.

> Если приложение должно абстрагироваться от базы, то это, 
на мой взгляд, очень специальное приложение, которое должно как-то решить 
вопрос этой абстракции.
Для этого и существуют ORM. ORM (Object Relationship Mapping) и есть эта абстракция и именно об абстракции мы и говорим.

> Мой модуль старается быть простым и понятным, т.е. это 
попытка свернуть "голый" SQL в перловые структуры данных и по записи всегда 
можно понять во что это развернётся в реальном SQL
SQL::Abstract для этого и придумали. Не только для этого, конечно. Они не мыслили так узко.

> Тригеры у меня в БД, если нужны, как и хранимые 
процедуры.
Вы на этапе архитектуры подписались на то, что у вас не будет высокой нагрузки, так как иначе будет боттлек в базе. И чем больше логики вы будете класть в базу (а вы будете это делать, по причинам вышеописанным) тем вам будет потом больнее это переделывать.

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

Thu, 15 Jan 2015 15:37:11 +0100 от PEF Secure <pef-secure на yandex.ru>:
>On Thursday, January 15, 2015 16:39:40  Warstone на list.ru wrote:
>>  Вообще есть 2 школы решения проблемы "Как работать с базой":
>> 1) Все в СУБД
>> 2) Все в Программе.
>> [...]
>> Мои разглагольствования сводятся к двум мыслям:
>> Голый SQL это плохо, если вы не умеете сахар на приложении.
>> "ORM должен уметь триггеры и много чего еще, чтобы им пользовались не только
>> вы". У вас оно есть?.. А стоит-ли начинать?
>> 
>> Простите, если вбросил.
>
>Моя позиция примерно такая: в реальном приложении, обычно, заранее известно 
>что за база будет использоваться, поэтому использование голого SQL вполне 
>нормальное явление. Если приложение должно абстрагироваться от базы, то это, 
>на мой взгляд, очень специальное приложение, которое должно как-то решить 
>вопрос этой абстракции. Когда же мне приходится писать приложение, то база 
>известна заранее. Мой модуль старается быть простым и понятным, т.е. это 
>попытка свернуть "голый" SQL в перловые структуры данных и по записи всегда 
>можно понять во что это развернётся в реальном SQL, кроме того, реальный SQL в 
>модуле не отменяется. Тригеры у меня в БД, если нужны, как и хранимые 
>процедуры. Т.е. между 1 и 2 я выбираю середину :)
>-- 
>PEF Developer
>-- 
>Moscow.pm mailing list
>moscow-pm на pm.org |  http://moscow.pm.org

----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150115/095d9fed/attachment-0001.html>