модели к базе данных, если ее подключение и функция лежат в отдельном модуле? При импорте функции и нескольких запросах (либо паре неверных запросах) пишет что сокет закрыт с другой стороны (socket has been ended by other party)
1. Подключение к БД вынести в фазу инициализации приложения 2. НЕ открывать .listen в HTTP сервисе до выполнения п. 1 3. Предоставить в MVC уже готовый проинициализированный интерфейс для выполнения запросов, а не тот интерфейс, который выполнит подключение 4. Использовать Connection Pool, чтобы держать необходимое количество резервных соединений с БД. Обычно это опция конфигурации подключения или самой библиотеки, которая используется для вашей БД 5. Наверняка в документации к библиотеке или ORM для используемой БД есть что-нибудь вроде Keep Alive для соединений, обычно есть Active Record и Data Mapper это всего лишь паттерны. Модель сама не делает запрос к БД, ей нужен интерфейс нижележащего уровня, т.е. п. 1. Попробуйте разобраться с зависимостями уровней и очерёдностью фаз и может быть тогда можно будет не смешивать фазы жизненного цикла данных с фазами жизненного цикла приложения и оно само собой решится )
Я подключаю бд в отдельном файле в конфиге, а .listen - в самом конце файла, который запускаю. Есть корневой класс модели, где есть основные методы, которые я вызываю в соответствующем контроллере, а его у свою очередь вызываю в роуте. Может, я что-то не так делаю, но во всех примерах всю логику пишут прямо в корневом файле. Извиняюсь, я новичок
не за что извиняться, все были новичками просто из вашего описания создаётся ощущение, что вы вызываете .connect к БД в контроллере Какая БД у вас и что для неё используете из NPM?
Express mysql2. Я с утра покажу пример, если Вам не трудно посмотреть
no problem
на строке 9 return не нужен передавать объекты req и res непосредственно в интерфейс запросов к БД бесчеловечно, даже если никто не будет читать этот код — это бесчеловечно по отношению к себе в первую очередь ) делать, конечно, можно что угодно, но это "против природы", потому, что здесь две доменные области в одном методе — ответ на HTTP запрос совмещён с запросом в БД. То есть dbQuery должен принимать данные, и возвращать их же.
так тоже Sub Optimal можно делать как угодно, конечно, но я бы почитал: https://sequelize.org/master/manual/getting-started.html То есть решение смешать обработку HTTP запросов в том же месте где идёт работа с данными в Persisten Storage приведёт к массе проблем в будущем. Разделите их по разным интерфейсам и тогда все эти сложные связи уйдут.
по-другому я не знаю как сделать, чтобы работало вне server.js) изначально я хотел делать запрос и возвращать ответ, в функцию, а уже его возвращать на фронтенд, но не получалось
нужно смотреть почему именно не получилось есть прекрасный Guide как именно смотреть, так, чтобы не было больно: https://nodejs.org/en/docs/guides/debugging-getting-started/
я пересмотрел кучу видео и перечитал кучу статей, все как 1 пишут все прямо в server.js. я хотел разделить эту логику, пытаюсь сделать подобие mvc, чтобы логика была в модели, а контроллер просто дергал нужный метод по надобности. и как тогда поступить лучше, чтобы не импортировать везде и всюду dbQuery? к тому же нужно ли завершать соединение в конце? если я его завершаю, запрос обрывается и пишет что соединение закрыто. если я на фронте буду быстро обновлять данные, то выскочит ошибка что сокет закрыт. боль :)
Обсуждают сегодня