Еще про ORM
Интерсную мысль нашел в статье. tldr: когда ORM используется за рамками CRUD, то он начинает только мешать, а за рамками CRUD находится большинство приложений.
Т.е. идея упростить или абстрагировать код с помощью ORM возможно имеет очень ограниченный контекст применимости.
В итоге при использовании ORM обычно получается что-то вроде проектирования своей бд прямо в коде (сущности и их взаимосвязи), и борьба с проблемами производительности никуда не денется всё равно, как ни абстрагируй. Язык запросов в виде цепочки объектов и методов читается хуже, чем SQL, по сути это особый язык, который надо учить. За себя скажу, что когда писал на PHP (Laravel), длинные запросы на Eloquent меня иногда изумляли своей сложностью чтения.
В итоге, кстати, некоторые производители ORM даже пытаются прикрутить свой собственный абстрактный недоSQL на объектах бизнес логики, например как в DOCTRINE:
```
или Hibernate:
В итоге непонятно, для чего козе боян, ведь обычный SQL - это и так абстракция над бизнес-сущностями и их взаимосвязями, и обвешивать это еще одним слоем с птичьим языком (или тем более с птичьим SQL-языком), игнорируя все проблемы перформанса - это просто странно. А под капотом ORM делает иногда такое, что волосы дыбом.
Есть еще такое мнение, что ORM - это как слой, абстрагирующий от способа хранения. Типа, сегодня ты пишешь на MySQL, завтра на Postgres, после завтра вообще в файлах хранишь - и тебе пофиг, код остаётся тем же. Чистая архитектура.
Ну это вообще хрень, конечно. Уродовать код и замедлять разработку, чтобы с вероятностью 0.01% захотеть переехать на другую базу - ну такое.
Про чистоту архитектуры тоже можно вставить 5 копеек, чтобы два раза не вставать. Очень часто слои пересекаются. Ты как ни крути, но делать абсолютно 100% независимый слой бизнес-логики (юзкейсы, сервисы) - это иногда бывает очень дорого. Например, если тебе надо построить хитрый отчет, ты будешь использовать SQL с группировками, оконными функциями, фильтрами и джойнами, выжимая из базы данных всё, что можно, включая хаки. Там будет не до абстракций. Да просто сделать group by и посчитать количество тех, у кого count больше одного - это ведь уже бизнес-логика в SQL.
НО
С другой стороны, писать совсем простейшие запросы вручную задалбывает, конечно, поэтому какой-то гибридный подход наверно может и подойти в некоторых ситуациях. Но даже в простых вещах нужно быть осторожным: на практике встречал удивление а-ля "а почему у нас при формировании этой страницы к базе уходит 254 запроса, мы ж только табличку вывели?"
Интерсную мысль нашел в статье. tldr: когда ORM используется за рамками CRUD, то он начинает только мешать, а за рамками CRUD находится большинство приложений.
Т.е. идея упростить или абстрагировать код с помощью ORM возможно имеет очень ограниченный контекст применимости.
В итоге при использовании ORM обычно получается что-то вроде проектирования своей бд прямо в коде (сущности и их взаимосвязи), и борьба с проблемами производительности никуда не денется всё равно, как ни абстрагируй. Язык запросов в виде цепочки объектов и методов читается хуже, чем SQL, по сути это особый язык, который надо учить. За себя скажу, что когда писал на PHP (Laravel), длинные запросы на Eloquent меня иногда изумляли своей сложностью чтения.
В итоге, кстати, некоторые производители ORM даже пытаются прикрутить свой собственный абстрактный недоSQL на объектах бизнес логики, например как в DOCTRINE:
```
php
$query = $em->createQuery('SELECT u FROM Doctrine\Tests\Models\Company\CompanyPerson u
WHERE u INSTANCE OF Doctrine\Tests\Models\Company\CompanyEmployee');```
или Hibernate:
java
IQuery q = s.CreateQuery("from foo in class Foo where foo.Name=:Name and foo.Size=:Size");
В итоге непонятно, для чего козе боян, ведь обычный SQL - это и так абстракция над бизнес-сущностями и их взаимосвязями, и обвешивать это еще одним слоем с птичьим языком (или тем более с птичьим SQL-языком), игнорируя все проблемы перформанса - это просто странно. А под капотом ORM делает иногда такое, что волосы дыбом.
Есть еще такое мнение, что ORM - это как слой, абстрагирующий от способа хранения. Типа, сегодня ты пишешь на MySQL, завтра на Postgres, после завтра вообще в файлах хранишь - и тебе пофиг, код остаётся тем же. Чистая архитектура.
Ну это вообще хрень, конечно. Уродовать код и замедлять разработку, чтобы с вероятностью 0.01% захотеть переехать на другую базу - ну такое.
Про чистоту архитектуры тоже можно вставить 5 копеек, чтобы два раза не вставать. Очень часто слои пересекаются. Ты как ни крути, но делать абсолютно 100% независимый слой бизнес-логики (юзкейсы, сервисы) - это иногда бывает очень дорого. Например, если тебе надо построить хитрый отчет, ты будешь использовать SQL с группировками, оконными функциями, фильтрами и джойнами, выжимая из базы данных всё, что можно, включая хаки. Там будет не до абстракций. Да просто сделать group by и посчитать количество тех, у кого count больше одного - это ведь уже бизнес-логика в SQL.
НО
С другой стороны, писать совсем простейшие запросы вручную задалбывает, конечно, поэтому какой-то гибридный подход наверно может и подойти в некоторых ситуациях. Но даже в простых вещах нужно быть осторожным: на практике встречал удивление а-ля "а почему у нас при формировании этой страницы к базе уходит 254 запроса, мы ж только табличку вывели?"