R
Там компонентный
<Route history={history} path='/home' component={Home} />
Вы про этот компонентный? или нет?
Вы про этот компонентный? или нет?
<Route history={history} path='/home' component={Home} />
Вы про этот компонентный? или нет?
Size: a a a
2020 October 05
B
не согласен, без ORM чаще говнокод появаляется
Это говорит о компетентности программистов, которые отвыкли делать это сами
R
да
а чем он отличается от вьюшного?
const routes = [
{ path: '/foo', component: Foo },
{ path: '/bar', component: Bar }
]
const routes = [
{ path: '/foo', component: Foo },
{ path: '/bar', component: Bar }
]
A
Холиварная слегка тема, на данный момент я увидел лишь то, что разрабов орм балует и выходят очень тяжёлые запросы.
B
Ну и я изначально сказал, если проект уровня интернет-магазина, орм действительно скорее будет плюсом. Если что-то серьезнее, то на возню с ним уйдет больше времени, чем на sql, а конечный результат все равно будет медленнее
A
Может в какой то другой вселенной всё обстоит иначе
A
а чем он отличается от вьюшного?
const routes = [
{ path: '/foo', component: Foo },
{ path: '/bar', component: Bar }
]
const routes = [
{ path: '/foo', component: Foo },
{ path: '/bar', component: Bar }
]
ты же сам ответил только что на свой вопрос
R
ты же сам ответил только что на свой вопрос
хочу услышать ваши мысли
Д
Я считаю, что правильно совмещать orm и raw, но надо все время смотреть что генерит orm
++
N
Sublime! resolvereject got +1 from old_deda. 6 karma in total.
Д
ORM, ActiveRecord можно использовать но осмысленно
GS
Ну и я изначально сказал, если проект уровня интернет-магазина, орм действительно скорее будет плюсом. Если что-то серьезнее, то на возню с ним уйдет больше времени, чем на sql, а конечный результат все равно будет медленнее
Тонкая ОРМ позволяет строить запрос максимально близко к SQL. Тут нет причин проседать в производительности.
Основная её задача - это Маппинг делать, это же орМ.
Если в проекте местами специфические запросы, то можно совмещать, и использовать SQL там, где он лучше, но всё ещё оставляя ОРМ для основной задачи - маппинг.
Полностью RAW SQL имеет смысл обычно тогда, когда за SQL отвечают отдельные люди, а не разработчики "остального" приложения, которые уже будут знать не только, как запросы делать, а ещё как их анализировать и выбирать оптимальные в сложных ситуациях, в том числе за пределами самого запроса.
Но какой-то маппинг всё равно надо будет потом писать, ведь в итоге в коде работать с объектами хотим
Основная её задача - это Маппинг делать, это же орМ.
Если в проекте местами специфические запросы, то можно совмещать, и использовать SQL там, где он лучше, но всё ещё оставляя ОРМ для основной задачи - маппинг.
Полностью RAW SQL имеет смысл обычно тогда, когда за SQL отвечают отдельные люди, а не разработчики "остального" приложения, которые уже будут знать не только, как запросы делать, а ещё как их анализировать и выбирать оптимальные в сложных ситуациях, в том числе за пределами самого запроса.
Но какой-то маппинг всё равно надо будет потом писать, ведь в итоге в коде работать с объектами хотим
GS
мне, как студню, походу придется его учить. Ибо больше половины вакансий требуют. А так я его тоже не люблю. Видел, что такое орм на серьезном проекте. Проще уж на sql запросы пакидать
Для вакансий важнее, имхо, не конкретную ОРМ выучить, а основные паттерны, в которыхъ они работают, а их не так много
B
Тонкая ОРМ позволяет строить запрос максимально близко к SQL. Тут нет причин проседать в производительности.
Основная её задача - это Маппинг делать, это же орМ.
Если в проекте местами специфические запросы, то можно совмещать, и использовать SQL там, где он лучше, но всё ещё оставляя ОРМ для основной задачи - маппинг.
Полностью RAW SQL имеет смысл обычно тогда, когда за SQL отвечают отдельные люди, а не разработчики "остального" приложения, которые уже будут знать не только, как запросы делать, а ещё как их анализировать и выбирать оптимальные в сложных ситуациях, в том числе за пределами самого запроса.
Но какой-то маппинг всё равно надо будет потом писать, ведь в итоге в коде работать с объектами хотим
Основная её задача - это Маппинг делать, это же орМ.
Если в проекте местами специфические запросы, то можно совмещать, и использовать SQL там, где он лучше, но всё ещё оставляя ОРМ для основной задачи - маппинг.
Полностью RAW SQL имеет смысл обычно тогда, когда за SQL отвечают отдельные люди, а не разработчики "остального" приложения, которые уже будут знать не только, как запросы делать, а ещё как их анализировать и выбирать оптимальные в сложных ситуациях, в том числе за пределами самого запроса.
Но какой-то маппинг всё равно надо будет потом писать, ведь в итоге в коде работать с объектами хотим
Ну есть же разработчики, которые сильны в теории баз и прочего. Им не нужен отдельный оптимизатор, они сами всегда лучше напишут. Тут орм скорее нужен как костыль для криворуких, а не ускоритель разработки. Потому что при наличии большого количества связанных таблиц орм часто начинает адски тупить. И в итоге там конфиги орма (через аннотации, например) занимают 70% исходников (доводилось видеть такие проекты). И быстродействие так себе. При желании все это можно заставить работать, и даже оптимизацию подтянуть, но на это уйдет больше времени и сил, чем на изучение sql и теории баз данных (которые в каком-то базовом виде уже должны быть известны даже с орм)
V💊
мне, как студню, походу придется его учить. Ибо больше половины вакансий требуют. А так я его тоже не люблю. Видел, что такое орм на серьезном проекте. Проще уж на sql запросы пакидать
к сожалению ты видел говнокод на орм скорее всего, если там программистам дать вместо орм чистый сиквел, то будет как максимум не лучше.
Д
В кривых руках любой хороший паттерн станет антипаттеррном
B
Для вакансий важнее, имхо, не конкретную ОРМ выучить, а основные паттерны, в которыхъ они работают, а их не так много
Ну я пока не устраивался, просто вижу, что в 70% вакансий на бэк на жабе требуют знание гибернейта (самый известный орм там). Мне это не нравится, но видимо надо соответствовать рынку
GS
Ну я пока не устраивался, просто вижу, что в 70% вакансий на бэк на жабе требуют знание гибернейта (самый известный орм там). Мне это не нравится, но видимо надо соответствовать рынку
Наличие ORM, ориентированных на энтерпрайз, к слову, очень противоречит мнению, что энтерпрайз не совместим с орм
V💊
кстати как 2 противоборствующих лагеря можно приводить Го и Раст ;)
первые не юзают ОРМ в продакшене зачасту. и пишут в лучшем случае через query builder. а у вторых есть ОРМ одна и её юзают все и не жалуются на производительность)
первые не юзают ОРМ в продакшене зачасту. и пишут в лучшем случае через query builder. а у вторых есть ОРМ одна и её юзают все и не жалуются на производительность)