Подавляющее количество реализаций ORM в других языках базируется на active record, окей можно сделать row data gateway на базе оного и жить. В Python есть sqlalchemy, в ruby datamapper, в php есть Doctrine. Для nodejs я вообще не видел вменяемой реализации ORM, обычно все весьма примитивно.
Я видел как разработчики тратили день на задачу, которая при помощи dao решается за пол часа. Как они боролись с ограничениями ORM при помощи тех же кешей и тд. в то время как им нужно было просто в этом конкретном случае сделать sql запрос и замэпить результат на какую-то структурку. Вот как вы репорты делаете с ORM? Допустим у вас есть миллион записей в базе и вы должны в качестве результата получить 3 числа, минимальное значение чего-нибудь, максимальное, медиана. Вы же не будете грузить миллион объектов, так? Вы воспользуетесь каким-то *QL, что бы описать выборку и получить эти числа.
Я не говорю что "не юзайте ORM", хотя и такие фанатики есть. Я лишь говорю что некоторые задачи намного проще решать при помощи dao. В большинстве случаев это работа с read model и выборками. Когда нам нужно просто сделать агрегацию данных какую-то и вывести ее.
Или, например, разработчики зацикливаются на том что "у меня есть mysql и я должен делать все на ней". В то время как никаких проблем сделать агрегацию в какую-нибудь эластику, или хранить связи между объектами в neo4j, в рамках конкретной задачи проще и эффективнее.
Петр: действие не прописывается в url, в url описываются ресурсы. В этом кардинальная разница в понимании того что есть rest а чем он не является.
Вы можете сделать отдельный ресурс, который описывает коллекцию действий над какой-то сущностью. И вы просто создаете кучу ресурсов.
Ну то есть никаких ограничений.
А что до "плодить урлы" - тогда вы начинаете запихивать в респонсы какие-то идентификаторы "что пришло". Структуры данных и т.д. уже усложняются. Ну то есть шило на мыло.
json rpc (когда все действия исключительно через POST, даже на выборку) сложнее масштабировать. Вот и все.
Алексей Черемисин: речь идет не о массивных выборках а в том что вам для генерации репорта с ORM придется загрузить кучу объектов в память, что-то с ними сделать и агрегировать какой-то результат. Причем то же самое можно сделать средствами SQL.
Что до вашей статьи - повторюсь. Если надо учитывать все то что описано в приведенной вами статье, какие-то кэши подключать и тд. это уже должно намекать на оверхэде. Все зависит от задачи, иногда это выгодно, а иногда проще вытянуть данные напрямую из базы в том виде в котором нужно. Но это все попахивает кастылями.
Не нужно просто зацикливаться и ставить "что-то по дефолту". Это всегда приводит не не самым эффективным решениями.
1) окей, я упростил конкретную реализацию до подхода.
2) ORM не про модель данных, он тупо про мэппинги раз уж на то пошло. И я привел пример конкретной реализации - hibernate, оно не про модель данных, оно про объектную модель.
3) Повторюсь, оно работает эффективно при малом количестве объектов. Для вещей вроде сложных выборок их не стоит использовать. Вы же помните что сталось с идеей объектно ориентированных баз данных?
4) а потом мы удивляемся почему простая штука на java жрет гигабайты памяти.
5) очень конструктивно.
6) все записи в базе будут загружены в память, куча лишних действий, которые можно заменить одним вызовом метода в dao.
thorii: ну на всякий напишу конкретнее. Прототип это фабрика, которая вместо того что бы создавать новое клонирует старое. Иногда это профитнее в плане затрат на ресурсы.
Простите, а зачем вообще делать такие проверки? При помощи всяких там TypeScript/Flow можно описать типы, и использовать статический анализатор. А в рантайме - какая разница проверяем мы и кидаем ошибку или за нас это делает сам рантайм? Кода меньше - результат тот же.
Юрий: тут кто-то говорил о своем фреймворке я не пойму? Пересмотрел еще раз вопрос - да, там намекается на фреймворк свой. И да согласен - это бред полный. Особенно когда за плечами нет 10-ти лет опыта с разными фреймворками.
Юрий: и? альтернативы как бы нет. Шаблон проектов либо придется замарозить и потом "сваять новый" или страдать с ним из покон веков. А сделать его сразу и хорошо опять же выйдет только если у вас за плечами 10 поколений таких шаблонов проектов.
А поддержка проектов - это всегда боль. Шаблоны проектов тут не причем. К примеру у меня есть шаблон проекта который я начал делать... года 2 назад. И начинался он как стандартный symfony проект с ansible + vagrant. Спустя год шаблон перекочевал на докер. Сейчас у меня сильно кастомизированная структура проектов, тесты и все такое. И знаете что забавно? Недавно ко мне пришел один из "тех" проектов, который были в самом начале. Надо было быстренько что-то поправить и т.д. И Сейчас оно с пол пинка уже не завелось даже. Перевод проекта на "новый" шаблон занят 6 часов работы. Для проектов где время на суппорт отведено мало так загоняться наверное не стоит, но все же...
Юрий: большая часть фреймворков написано процедурно с классами для изоляции и управления зависимостями. Посмотрите на Yii - там от ООП только классы. Но свою задачу вполне выполняет.
Чистое ООП во фреймворках - нонсенс. Ну и повторюсь, что бы ваше ООП было лучше вам надо знать и структурное и функциональное программирование. Можно не знать про монады, но общая идея функциональщины должна быть понятна. Так же понятна как чем плохи глобальные переменные или статические свойства у классов (и когда на это можно наплевать и сделать).
Юрий если добавить к ООП функциональное программирование - то вы получите чуть более правильное ООП. Процедурное взаимодействие с внешним миром и функциональная логика с отсутствием состояния. По моему мнению это прекрасно. НО в PHP действительно чисто функциональные концепции пока трудно реализуемы. Но общие идеи осознать стоит. В особенности почему функциональное программирование является самой старой парадигмой (лямда исчисления придумали еще в 30-х годах, а первый функциональный язык появился во времена коболов и фортранов), а хайп вокруг только сейчас.
p.s. Вообще лично я не уверен что стоит заставлять людей изучать ООП. Они так или иначе придут к этому. Один мой знакомый пару лет назад пытался меня убедить что первый год разработчик должен разбираться исключительно со структурным программированием, а потом уже лесть в функциональщину и ООП. Я только спустя полтора года начал понимать что возможно он был прав.
Зависит от сферы деятельности. Большинство интересует максимум знаком ли разработчик с алгоритмической сложностью, и то на уровне "объясни какую сложность имеет вставка в хэш мэпу".
Потому у меня вопрос, вам зачем? Вы хотите именно в сферу где надо много математики? Нейронные сети, DSP и т.д.?
aleserkan: но сразу скажу - если мы пишем бложик и там не надо "все динамично" - то SPA нафиг не нужны. А вот каталог товаров где все должно быть динамичным - тут уже разница в цене будет на стороне SPA.
по приведенной вами ссылке не изоморфное приложение, то есть без серверсайд пререндринга. О чем мы тогда говорим?
Для angular2 из коробки доступно вполне годное решение. И да, rest + spa с точки зрения распаралеливания разработки выходит выгоднее. Да и с точки зрения инструментариев так же.
aleserkan: решается изоморфностью или хотя бы серверсайд пререндерингом. Даже на 1.5 это можно делать относительно удобно (я даже как-то делал на jsdom и выходило весьма быстро, но на двойке удобнее)
В целом тут вопрос больше в трудозатратах. Если вам сайтик написать выходит в хотя бы в полтора раза быстрее и не требуется "динамизм" на клиенте - стоит задуматься.
Максим Иванов: ReactJS это только представление. Ну то есть это как если взять ангуляр и оставить в нем только компоненты. В целом "принципиальной" разницы как готовить приложения на реакте или на ангуляре сейчас нет. Идея примерно одинаковая - тупые компоненты без состояния, логика сверху где-то, компоненты только получают готовый стэйт и рисуют UI под него.
Подавляющее количество реализаций ORM в других языках базируется на active record, окей можно сделать row data gateway на базе оного и жить. В Python есть sqlalchemy, в ruby datamapper, в php есть Doctrine. Для nodejs я вообще не видел вменяемой реализации ORM, обычно все весьма примитивно.
Я видел как разработчики тратили день на задачу, которая при помощи dao решается за пол часа. Как они боролись с ограничениями ORM при помощи тех же кешей и тд. в то время как им нужно было просто в этом конкретном случае сделать sql запрос и замэпить результат на какую-то структурку. Вот как вы репорты делаете с ORM? Допустим у вас есть миллион записей в базе и вы должны в качестве результата получить 3 числа, минимальное значение чего-нибудь, максимальное, медиана. Вы же не будете грузить миллион объектов, так? Вы воспользуетесь каким-то *QL, что бы описать выборку и получить эти числа.
Я не говорю что "не юзайте ORM", хотя и такие фанатики есть. Я лишь говорю что некоторые задачи намного проще решать при помощи dao. В большинстве случаев это работа с read model и выборками. Когда нам нужно просто сделать агрегацию данных какую-то и вывести ее.
Или, например, разработчики зацикливаются на том что "у меня есть mysql и я должен делать все на ней". В то время как никаких проблем сделать агрегацию в какую-нибудь эластику, или хранить связи между объектами в neo4j, в рамках конкретной задачи проще и эффективнее.