TS
@tshemsedinov Вы говорили, что у Вас есть видео где Вы рассказываете про ORM. Не подскажете как оно называется?
Отдельной лекции про ORM у меня нет, это не достойно внимания, есть лекции про слой доступа к данным, и про СУБД, сейчас пришлю
Size: a a a
2020 April 15
TS
Вот тут все это собрано https://github.com/HowProgrammingWorks/Index/blob/master/Courses/Databases.md
D
@tshemsedinov Досмотрел вторую часть, получил массу удовольствия, очень круто изложенная и структурированная информация. С одним моментом не мог согласиться - отказ от ОРМ.
- На JS действительно нет нормальных (typeORM?)
- Качество генерируемой query мягкоговоря желает лучшего
- Ну и все вытекающие последствия
Но
- Если следовать Grasp/solid - переход от ORM к queryBuilder должен выглядеть как эволюционный процесс, недорогой и безопасный(тесты)
- Пока есть ограничения построения инфры и поднятия физических инстансов(такое часто бывает, инфраструктура может быть блокером) команда может писать на sqllite (главное, чтобы база было корректно спроектировано)
- На JS действительно нет нормальных (typeORM?)
- Качество генерируемой query мягкоговоря желает лучшего
- Ну и все вытекающие последствия
Но
- Если следовать Grasp/solid - переход от ORM к queryBuilder должен выглядеть как эволюционный процесс, недорогой и безопасный(тесты)
- Пока есть ограничения построения инфры и поднятия физических инстансов(такое часто бывает, инфраструктура может быть блокером) команда может писать на sqllite (главное, чтобы база было корректно спроектировано)
AZ
Я понимаю, но не могу же я слепо верить статьям на dzone :)
TS
Я понимаю, но не могу же я слепо верить статьям на dzone :)
слепо нет, но можно прочитать
TS
а мне можно и слепо поверить
AZ
слепо нет, но можно прочитать
Безусловно знаком, классический же труд
AZ
а мне можно и слепо поверить
Я пытаюсь подходить с критической точки зрения, но коллегам рекомендую твой материал как источник правды, который сравним с классиками
TS
Читайте классику, снова и снова.
Пушкина, Шемсединова, Толстого.
Если минут 5 в день задачник листать -
Мозг до курса третьего будет пахать.
Решайте за завтраком, решайте перед сном.
Когда вас положат после сессии в дурдом.
Пушкина, Шемсединова, Толстого.
Если минут 5 в день задачник листать -
Мозг до курса третьего будет пахать.
Решайте за завтраком, решайте перед сном.
Когда вас положат после сессии в дурдом.
Y
А почему ORM так активно используются в enterprise level frameworks если это такая концептуально плохая вещь?
TS
А почему ORM так активно используются в enterprise level frameworks если это такая концептуально плохая вещь?
Потому, что корпоративный сектор все заказывает на галерах, а там выгодно писать лапшу, чтобы потом саппортить ее было сложно. У всех крупных ИТ компаний, которые сами себе пишут ORM не используется, где слышно, что Google, FB, Yandex, Apple, Netflix, PayPal себе на ORM что-то написали?
Y
Потому, что корпоративный сектор все заказывает на галерах, а там выгодно писать лапшу, чтобы потом саппортить ее было сложно. У всех крупных ИТ компаний, которые сами себе пишут ORM не используется, где слышно, что Google, FB, Yandex, Apple, Netflix, PayPal себе на ORM что-то написали?
Ну, крупные компании это скорее исключение, как мне кажется (это не про ORM, а в принципе). Там все не так как у всех, и не всем нужно "как в Google"
TS
ORM дешевый для быстрого прототипирования и ужасен в поддержке, как и многие другие технологии, направленные на индустрию ПО. А цель индустрии - это больше разработки, а не больше результата.
A
@tshemsedinov а що Ви вчора мали на увазі під інтерфейсами в javascript? Проєктуйте інтерфейси. Коли в нас є Typescript та області видимості- то зрозуміло. А якщо немає?
A
Потому, что корпоративный сектор все заказывает на галерах, а там выгодно писать лапшу, чтобы потом саппортить ее было сложно. У всех крупных ИТ компаний, которые сами себе пишут ORM не используется, где слышно, что Google, FB, Yandex, Apple, Netflix, PayPal себе на ORM что-то написали?
StackOverflow використовує Dapper.
A
а мне можно и слепо поверить
Що тут малося на увазі?
TS
@tshemsedinov а що Ви вчора мали на увазі під інтерфейсами в javascript? Проєктуйте інтерфейси. Коли в нас є Typescript та області видимості- то зрозуміло. А якщо немає?
Я имею в виду контрактное программирование, я даже отвечал уже на вопрос этот, вроде, нужно тестами покрытвать интерфейс и использовать библиотеки для проверки контрактов.
Y
ORM дешевый для быстрого прототипирования и ужасен в поддержке, как и многие другие технологии, направленные на индустрию ПО. А цель индустрии - это больше разработки, а не больше результата.
Аргументы понятны. Спасибо за ответ!
V
Потому, что корпоративный сектор все заказывает на галерах, а там выгодно писать лапшу, чтобы потом саппортить ее было сложно. У всех крупных ИТ компаний, которые сами себе пишут ORM не используется, где слышно, что Google, FB, Yandex, Apple, Netflix, PayPal себе на ORM что-то написали?
Тимур, очень поверхностное заявление.
1. Нельзя делить все на черное и белое. В разработке наиболее важен здравый смысл. Догматическое следование каким-то бест-практисес может без проблем развалить проект. Всегда есть контекст и нужно смотреть по ситуации.
2. Есть масса успешных компаний, которые отлично развивались на ORM. Тут же basecamp и сейчас на ORM (есть видео от DHH классные про то, как они пишут код) Twitter изначально был на Ruby и ActiveRecord и это не значит, что им выгодна была лапша. Посмотри сколько проектов на RoR, я знаю техлидов с с PayPal и они совсем не против ORM.
3. Есть масса зафейленых стартапов, которые решили, что и не нужен ORM (и возможно еще, что обязательно нужны микросервисы). Им отсутвие ORM никак не помогло, а в некоторых случаях могли и стать причиной фейла.
4. Я не за ORM и не против. У нас есть и проекты на базе ORM и без ORM. Например, в платформе по автомтизации умного дома у нас не было ORM, у нас был репозитории объектов, что позволило нам кардинально поменять схему хранения не поменяв ни строчки кода бизнес-логики. Просто все зависит от контекста.
5. Да ORM накладывает ограничения и Гугл оно не подойдет, но давайте сначала станем, как Гугл :). Задача архитектора соотнести технические и бизнес риски. И возможно правильней сделать, к примеру, как твиттер (а может и нет, зависит от многих факторов)
6. Энтерпрайз приложения обычно содержат очень много справочников и много CRUD и поэтому ОРМы тут часто заходят
1. Нельзя делить все на черное и белое. В разработке наиболее важен здравый смысл. Догматическое следование каким-то бест-практисес может без проблем развалить проект. Всегда есть контекст и нужно смотреть по ситуации.
2. Есть масса успешных компаний, которые отлично развивались на ORM. Тут же basecamp и сейчас на ORM (есть видео от DHH классные про то, как они пишут код) Twitter изначально был на Ruby и ActiveRecord и это не значит, что им выгодна была лапша. Посмотри сколько проектов на RoR, я знаю техлидов с с PayPal и они совсем не против ORM.
3. Есть масса зафейленых стартапов, которые решили, что и не нужен ORM (и возможно еще, что обязательно нужны микросервисы). Им отсутвие ORM никак не помогло, а в некоторых случаях могли и стать причиной фейла.
4. Я не за ORM и не против. У нас есть и проекты на базе ORM и без ORM. Например, в платформе по автомтизации умного дома у нас не было ORM, у нас был репозитории объектов, что позволило нам кардинально поменять схему хранения не поменяв ни строчки кода бизнес-логики. Просто все зависит от контекста.
5. Да ORM накладывает ограничения и Гугл оно не подойдет, но давайте сначала станем, как Гугл :). Задача архитектора соотнести технические и бизнес риски. И возможно правильней сделать, к примеру, как твиттер (а может и нет, зависит от многих факторов)
6. Энтерпрайз приложения обычно содержат очень много справочников и много CRUD и поэтому ОРМы тут часто заходят