Люди приходят с PHP, где привыкли рендерить страницы на сервере, т.е. использовать шаблоны и MVC. А для ноды характерно, когда клиент SPA (single-page application) отделен от сервера сетевым API. Сервер отдает данные в JSON, а клиент уже рендерит их в HTML через шаблонизатор, MVC, или вот на Angular или React. Если это понять, то уже много времени сэкономите, не пытаясь делать 2 MVC, одно на сервере, а второе на клиенте и соединять их при помощи скотча и туалетной бумаги.
Я предлагаю Вам отказаться от этих сроков, потому, что Вы сейчас напишете страшный говнокод, если не изучите новый подход, а начнете просто решать проблему в лоб. Если не откажитесь от сроков, то и сроки сгорят и задачу не решите и не научитесь и код на выброс пойдет.
Дело реально плохо, Вы, похоже, писали на PHP раньше, а это другой стек программирования, все концепции другие, так с налету не пойдет. Пока Вы не поймете как работает нода и как работает монга, то ни какого сетевого API не напишите. Берите Хабр и читайте неделю статьи, найдите тут на Тостере есть несколько подробных ответов, где даются ссылки на учебные материалы.
Используете Mongo, откуда взялись таблицы? Тут коллекции документов, данные нужно хранить в ненормализованном виде, без реляционной декомпозиции, т.е. если у айтема есть связанный пользователь, то его имя или идентификатор нужно хранить в айтеме. Нет джоинов в монге, можно конечно для каждого айтема делать отдельный запрос в базу, но это будет огромный поток запросов, очень не оптимально, вся идея монги, чтобы сократить кол-во обращений к базе, в идеале вообще делать один запрос при каждом обращении клиента к сетевому API. Все разом читаем и отдаем.
Эта библиотека не сможет вернуть значение, получаемое в асинхронном режиме из базы через return. Вам нужно перестроиться и начать использовать коллбеки для возврата результатов. Т.е. самому начать писать асинхронные либы. Одним из параметров в функции будет функция, куда Вы и передадите первым параметром err, а вторым - значение. Если ошибки нет, то вернете null в err.
Естественно, возвращается массив, если Вы не научитесь отлаживать хотя бы через console.dir(); то будет очень сложно жить. Один объект возвращает findOne.
copal: в первой цитате говорится об автоматах во второй про модель акторов. Это разные вещи, даже противоположные в каком-то смысле. Автоматы работают пошагово, выполняют одну операцию за квант времени, а актоары работают параллельно, группа акторов может исполнять параллельно разные действия, хотя поток событий, приводящие их движение, может быть один общий.
Парадигма программирования называется автоматное программирование, а паттерна там два (автомат мура и автомат мили), это когда есть определенный набор состояний системы и заданы правила переходов из состояния в состояние. Правила могут быть заданы как логические или математические выражения, как функции, как декларативные конструкции, но суть в том, что мы имеем сеть (граф), например https://ru.wikipedia.org/wiki/Сети_Петри или есть еще Р-модели (которые разрабатывает, например, проф. Вельбицкий) и есть дуги переходов. Автомат может одновременно находиться в одном состоянии, и переходить по той дуге, в которой срабатывают условия в другое состояние. Игровой мир строится из множества автоматов.
Модель акторов это когда процессы или объекты не взаимодействуют друг с другом напрямую, а могут посылать/получать в/из шины событий сообщения. Это позволяет создавать, например, игровые миры, которые обсчитываются сотнями и тысячами серверов. Вообще акторы используются не только в играх, а это одна из базовых технологий для параллельных вычислений.
Я не стараюсь Вас как-то обидеть, просто пытаюсь показать, что мир не сошелся клином на mvc и это не самый передний фронт и не самая последняя технология. Мир намного разнообразнее, а функциональное и реактивное программирование это не прошлый век, исследования и разработки в этом направлении более современные, чем разработки в ООП. Почитайте пожалуйста статьи про facebook.github.io/react и про Web-components webcomponents.org Вообще, компонентный подход гораздо красивее, чем mvc, и веб наконец движется в этом направлении от ереси шаблонизаторов и нелепого разделения html, css и javascriot. Компонент - это все вместе, и верстка и стили и поведение, слепленные туго в визуальные контролы, как кнопка, список, дерево, меню и т.д. и уже дальше склеиваемые в композитные контролы. Сравните это с ересью ангулара и будет счастье, а этот подход использовался еще Delphi и сейчас живет в C# и Java. Только вот в вебе сразу не удалось его реализовать из-за войны браузеров и стандартов, которая до сего дня держала весь веб в состоянии дикости глухого средневековья. Почитайте про веб-компоненты и реакт на хабре. Нужно следить за передним краем технологий. habrahabr.ru/search/?q=%5Bweb%20components%5D&targ... и тут habrahabr.ru/hub/ReactJS И посмотрете habrahabr.ru/post/251835
Как говорит Жванецкий, «Давайте спорить о вкусе устриц с теми кто их ел». Из Ваших рассуждений очевидно, что другого опыта, кроме паттерна mvc у Вас нет. Весь мир Вы видите только через mvc. И модель для Вас - это модель из паттерна mvc и браузер по mvc построен и про ООП Вы знаете только отдаленные слухи из публикаций про mvc. Про другие парадигмы мало что слышали, как устроены браузеры, СУБД, операционные системы, компиляторы, память, процессор и вообще вычислительная техника, не имеете понятия, достаточного для спора. Из задач приводите примеры или совсем учебные или из области компьютерных игр, это очень маленький кругозор для серьезных обобщений. Вы не владеете даже общепринятой терминологией для инженерии, для программирования, для ООП и для архитектуры информационных систем. В таких условиях спорить с Вами совершенно бесполезно. Рекомендую почитать базовую литературу по программированию, Дэйкстру, Вирта, Кнута, Буча. Когда будете иметь представление, что такое архитектура фоннеймана и в чем особенность конечных автоматов (мура и мили), парадигму автоматного программирования, парадигму обобщенного программирования, парадигму реактивного программирования, парадигму функционального программирования, парадигму реактивного программирования, парадигму прототипного программирования и будете ее отличать от объектно-ориентированного и объектно-базированного программирования. По моделям данных пощупаете СУБД реляционные, графовые, документные, объектные и иерархические. Наберете хоть 5-7 лет практики, десяток языков программирования, сделаете обобщения, а пока, и обобщать-то Вам нечего. И почитайте прямо сейчас мнения супер-бизонов про ООП, которые поопытнее меня будут: blogerator.ru/page/oop_why-objects-have-failed Так что, это не только мое уникальное такое мнение сложилось, там под статьей есть ссылки и дополнения, все достаточно аргументировано.
Ну что тут подробнее, берите доку по докеру, статей куча, а тема понятная - вместо запуска каждого сервиса в отдельной виртуальной машине, запускаем в их в контейнерах, которые работают без виртуализации (используя одно общее ядро). Но контейнеры эти линуксовые, на винде Вам все равно понадобится виртуалка с линуксом, но это лучше, чем 4 виртуалки с линуксами. Экономия на памяти и ресурсах, на переключении контектов и разделении ресурсов между виртуалками. А экранирование приложений (сервисов) друг от друга полнейшее.
Ни кто не пишет приложение "человек", приложение может быть "информационная система учета человеков в больнице" или "система обучения человеков пилотированию самолетов" или "экспертная система социологических исследований на человеках". И "человек" живет внутри этих информационных систем. При этом "человек" - это не модель, это класс. Модель это вся совокупность классов, объектов, прототипов, структур данных, событий. Вы во всех сообщениях, когда хотите сказать ООП, говорите mvc, такое впечатление, то ООП без mvc не существует. Но mvc - это всего один из паттернов в рамках парадигмы программирования ООП, а кроме ООП есть и другие парадигмы, и эти парадигмы пораждают другие модели. Например, реактивное программирование порождает событийную модель предметной области, а функциональное программирование пораждает функциональную модель, могут быть их гибриды, это все разные модели. Вы даже ООП мыслите из рамок одного паттерна, если так смотреть, то не видно общей картины и кажется, что mvc подходит как нельзя лучше для всего-всего. Но в каких-то слечаях модель ориентированных графов, в которых вершина это состояние, а дуга это переход, может быть гораздо эффективнее ООП, не говоря уже про mvc. Идея моделей в том, что мы берем отдельный аспект моделируемой предметной области, реализуем программно не все, а только упрощенное отображение, представление, которого хватает для решения прикладной задачи.
Кроме моделей в приложениях от 10% до 90% может быть такого функционала, который даже не относится к моделям, например, операционная система вообще почти лишена моделей, все задачи, связанные с файловой системой, процессами, сетью, драйверами, окнами, выделением памяти, переключением контекстов - это все служебные задачи. Ладно, операционная система это отдельный случай, вот браузер - к нам ближе, и в нем, опять таки, нет ни каких моделей, браузер не модель "мира", в мире нет страниц, дерева DOM, HTTP-запросов, рендеринга, стилей, джаваскрипта, кукизов, все это служебные понятия. Теперь пример из прикладных приложений, в них тоже очень много не относящегося к моделям: логировние, драйвера доступа к базам данных, библиотеки шифрования и обработки изображений, математические библиотеки, доступ к API операционной системы, все, что связано с сериализацией/десериализацией и работой с форматами данных (JSON, XML, YAML, CSV, UTF-8, SVG, CSS, PDF и т.д.), все что связано с графическим интерфейсом (окна и компоненты, шаблоны, шрифты, стили, векторная графика, весь рендеринг), реализации прикладных протоколов HTTP/HTTPS, SMTP, IMAP/POP3, RDP, SSH и т.д., конфигурация (загрузка конфигурации, инициализация приложений из конфигурации и т.д.), задачи безопасности, шины событий, обработка ошибок, архивирование и распаковка, видео- и аудио-кодирование, захват видео и звука, обработка текста (синтаксический анализ, парсинг, регулярные выражения), я могу перечислять это еще 3 страницы. Задач, которые не укладываются ни в паттерн mvc, ни в парадигму ООП и даже вообще в концепцию моделирования, на порядок больше, чем тех, что укладываются.
Вы совершенно правы, что уродцы рождаются от того, что часто в коллективах нет архитекторов и постановщиков заданий, нет людей имеющих достаточный опыт, а задачу начинают решать после прочтения 2-3 статеек сомнительной ценности. Вот и получается, что применяют не соответствующие инструменты, не адекватные задачам.
copal: Я говорю о понятии модель в его научно-техническом смысле, так как его должен понимать инженер, в том числе и инженер-программист. Информационная модель содержит данные и логику моделируемой предметной области, но это еще не все данные логика приложения, приложение это граздо шире. Например, интерфейс пользователя протоколов передачи данных, форматов сепиализации и служебных функций приложения ни как не относится к предметной области.
