Вообще этот пример практически полностью повторяет структуру компонента\модели из Ember.js, в том числе контролем за состоянием, попробуйте, возможно вам понравится.
Такого не бывает, любой программист, ушедший чуть далее уровня университетских задачек на своем профессиональном пути, способен «решать бизнес задачи», «формировать под решение ТЗ», отличия лишь в качестве создаваемого решения. От чего зависит качество? Оно зависит от знания предметной области и технического уровня программиста.
Именно эти два критерия имеют значение, именно по этой причине в вакансиях ищется не абстрактный «инженер», а достаточно опытный программист со знанием стека и предметной области.
Кстати понятие «программист-инженер» немного напоминает понятие «настоящий мужчина», все говорят об нем, но в реальности никто его не видел.
Такой риск неприемлем для большинства проектов, data layer пакеты большие, а выделять деньги на их поддержку\исправление\дописывание никто не захочет. Проще и логичнее использовать более зрелую платформу, где уже присутствуют все необходимые инструменты. Ну или обходиться без них.
Понимаете, дело не в уникальности, а в самой сути паттерна Data Mapper, он предполагает абсолютную чистоту модели и не приемлет нахождения в ней дополнительной функциональности, в том числе методов сохранения.
Что касается иллюзий, я сам в повседневной жизни пользуюсь data layer на основе Active Record паттерна, вроде пока жив и вполне доволен. Но юзебельность AR никак не опровергает изначального тезиса, что под node.js нет достаточно распространенной data mapper orm, правда?
Посмотрите документацию и примеры кода, на аналог Hibernate это не слишком похоже. Взять хотя бы модели, сохраняющие сами себя…
https://github.com/balderdashy/waterline-docs
Doctrine2 это orm, в основе которой лежит data mapper паттерн, active record это его противоположность. По сути доктрина это клон hibernate из экосистемы java.
Очень странный странная статья, особенно в части упоминания технологий и яп:
Факт №1 — в статье упомянут mongoDB, но нет ни слова о реляционных бд\sql, что очень странно, так как mongo встречается на рынке довольно редко и чаще всего в достаточно сложных проектах, куда новичка не возьмут
Факт №2 — php лидирует на рынке, но упомянут в самом конце списка. Так же стоит упомянуть, что у php богатейшая экосистема, того же аналога https://github.com/doctrine/doctrine2 не найти под node.js\ruby
Факт №3 — ставить java\c# в один ряд с Python\PHP\JS\Ruby крайне странно, это совершенно разные весовые категории, на которых создаются совершенно разные классы продуктов
Станет сложным, как только понадобится уведомлять интерфейс о прогрессе текущей выполняемой операции, например запекании и остывании, применять поправки к рецепту, в зависимости от указаний пользователя. То есть когда задача выйдет за рамки простого вычисления.
Так же свою часть сложности внесет описание структур данных, они станут или очень сложными или многочисленными, например реальная духовка может быть крайне сложна и иметь огромное количество параметров. Можно конечно ввести структуру данных «духовка для пирога» и функцию «разогретьДуховкуДляПирога», но это было бы не слишком удобным решением.
Но все же хотелось бы увидеть примеры «космических кораблей на fp», в подтверждение вашего предыдущего высказывания, так как мне таковые еще не встречались.
Не могу согласиться, в большей части «космических кораблей» разработчики стараются придерживаться максимально простых решений. Пример тому — ядро linux (даже с++ не рискуют брать, не говоря уже о фп языках), openJDK, postgres, каждый из вышеперечисленных проектов решает сложнейшие задачи, но написан почему-то во вполне императивной парадигме.
В качестве контраргумента могу предложить перечислить крупные opensource проекты, которые написаны преимущественно с fp подходом.
С ангуляром эти библиотеки вполне совместимы, к бекенду так же требований практически не предъявляют за исключением протокола (чаще всего используется jsonapi.org), но и это вполне преодолимо, так как в большинстве data layer возможно написание адаптеров под свое api.
Очень похоже на клиентские data layer пакеты, вроде ember-data, orbit.js, fortune.js, особенно в части построения графа зависимостей, оптимизации запросов, кешировании.
Автор, вы их не рассматривали?
Тут критерий намного проще и он никак не связан с «инженерами». В современном проекте с мощной фронтенд частью такой код, особенно от начинающего разработчика (а статья именно для них) просто неприемлем, он элементарно не пройдет ревью. Следовательно читать такой код нужно только для расширения кругозора, но никак не в качестве production ready варианта.
В качестве аналогии приведу php4, можно развешивать на харбре гайды об эмуляции ооп и паттернах процедурного программирования, а можно давать актуальную на данный момент информацию по php5\7 и делать мир лучше.
Никакие «тыжеинженер» «этооснова» не оправдывают такого порядка подачи материала. Это просто глупо и нерационально.
Про протитипы знать несомненно надо, но точно не в контексте «собираем на коленке очередную систему прототипного наследования». Пример адекватной на мой взгляд подачи материала для новичков — https://learn.javascript.ru/, где легаси подходы честно помечены и подаются в последнюю очередь и с соответствующим предупреждением.
Посмотел вашу книжку, простите, она никуда не годится. Там есть замечательная глава «заимствование конструктора» с примерно таким содержанием:
function StaticPage() {
Article.call(this);
}
Наверное вы правы, но это решение разработчика, с чем связываться, а с чем нет. На рынке достаточно проектов, где про существование IE8 можно забыть, правда это большей частью фронтендерские вакансии, что стоит признать.
Проблемы частично решаемы, в стилях — автопрефиксерами, в коде — транспайлерами, но все же с легаси лучше не связываться, себе дороже.
Кстати отказ совместимости со старыми браузерами уже давно вошел в тренд, вполне возможно что автообновление браузеров утопит IE8 куда быстрее чем мы думаем.
Ну вы же сами сейчас привели в пример поддержку легаси браузера. Потому и устарели.
Сейчас новичкам (а это статья именно для них) рекомендовал бы в первую очередь учиться писать адекватный es6 код, пользоваться экосистемой и следить за новостями, а не учиться поддерживать легаси, которое отвалится раньше, чем они освоятся в веб разработке.
Именно эти два критерия имеют значение, именно по этой причине в вакансиях ищется не абстрактный «инженер», а достаточно опытный программист со знанием стека и предметной области.
Кстати понятие «программист-инженер» немного напоминает понятие «настоящий мужчина», все говорят об нем, но в реальности никто его не видел.
Что касается иллюзий, я сам в повседневной жизни пользуюсь data layer на основе Active Record паттерна, вроде пока жив и вполне доволен. Но юзебельность AR никак не опровергает изначального тезиса, что под node.js нет достаточно распространенной data mapper orm, правда?
https://github.com/balderdashy/waterline-docs
Факт №1 — в статье упомянут mongoDB, но нет ни слова о реляционных бд\sql, что очень странно, так как mongo встречается на рынке довольно редко и чаще всего в достаточно сложных проектах, куда новичка не возьмут
Факт №2 — php лидирует на рынке, но упомянут в самом конце списка. Так же стоит упомянуть, что у php богатейшая экосистема, того же аналога https://github.com/doctrine/doctrine2 не найти под node.js\ruby
Факт №3 — ставить java\c# в один ряд с Python\PHP\JS\Ruby крайне странно, это совершенно разные весовые категории, на которых создаются совершенно разные классы продуктов
Так же свою часть сложности внесет описание структур данных, они станут или очень сложными или многочисленными, например реальная духовка может быть крайне сложна и иметь огромное количество параметров. Можно конечно ввести структуру данных «духовка для пирога» и функцию «разогретьДуховкуДляПирога», но это было бы не слишком удобным решением.
В качестве контраргумента могу предложить перечислить крупные opensource проекты, которые написаны преимущественно с fp подходом.
Автор, вы их не рассматривали?
В качестве аналогии приведу php4, можно развешивать на харбре гайды об эмуляции ооп и паттернах процедурного программирования, а можно давать актуальную на данный момент информацию по php5\7 и делать мир лучше.
Никакие «тыжеинженер» «этооснова» не оправдывают такого порядка подачи материала. Это просто глупо и нерационально.
Посмотел вашу книжку, простите, она никуда не годится. Там есть замечательная глава «заимствование конструктора» с примерно таким содержанием:
function StaticPage() {
Article.call(this);
}
Шел 2016 год…
Кстати отказ совместимости со старыми браузерами уже давно вошел в тренд, вполне возможно что автообновление браузеров утопит IE8 куда быстрее чем мы думаем.
Сейчас новичкам (а это статья именно для них) рекомендовал бы в первую очередь учиться писать адекватный es6 код, пользоваться экосистемой и следить за новостями, а не учиться поддерживать легаси, которое отвалится раньше, чем они освоятся в веб разработке.