AF
и таких контроллеров с такими методами хватает
Size: a a a
2020 November 22
AF
меня смущает подход нестjs - метод задекорирован пачко декораторов, какая-то кастомная проверочка в методе + один метод сервиса
M
вот например постовый метод:
http://joxi.ru/4Akaq0oFkKoLwm
http://joxi.ru/4Akaq0oFkKoLwm
А откуда papyrus берется, интересно
AF
папирус, это мой кастомный файл с текстовыми заглушками
AF
чтобы хардкода не было в контроллерах, сервисах
AF
Можно сделать аргумент резолвер, который смапит запрос на структуру с нужным форматом
в несте всё это уже есть, не надо ничё там велосипедить
AF
там и так уровней абстракций и техник с подходами 🤯
ЕР
в несте всё это уже есть, не надо ничё там велосипедить
Ну в чем проблема тогда?
ЕР
Валидацию - в миддлвари(декораторы), и контроллер принимающий реквест становится ни нужон
AF
смущает скромненький один метод в большинстве методов контроллеров
M
папирус, это мой кастомный файл с текстовыми заглушками
В смысле откуда переменная берется
AF
типа есть понятие тонкий контроллер и всё такое
AF
но не плоский же)
a
@andrey_furman там в несте есть поддержка swagger/grapql, попробуй посмотреть как они внутри обходится без контроллеров
AF
Хорошо, гляну, спасибо, ребя. Нужно бежать... отпишусь
M
вот например постовый метод:
http://joxi.ru/4Akaq0oFkKoLwm
http://joxi.ru/4Akaq0oFkKoLwm
Метод getAvailableFormats с переменной внутри откуда берутся? Это глобально все объявлено что ли?
M
но не плоский же)
От этого хуже не будет, может быть просто избыточно
М
привет всем. Пишем бизнес-логику для приложеньки одной на nest.js
И получается так, что в контроллера есть декораторы,которые занимаются валдированием входящих параметров методов реста, и, по сути, в каждом методе контроллера вызываем один метод сервиса, который относится к этому модулю.
Уже в сервисе ми работаем с бд черезе репозитории орм-ки (typeorm) и другими сервисами.
Всё вродь неплохо, но меня смущает то, что в методе контроллера юзается только один метод его сервиса, где и происходит вся бизнес-логика.
Что здесь не так? подскажите плиз.
И получается так, что в контроллера есть декораторы,которые занимаются валдированием входящих параметров методов реста, и, по сути, в каждом методе контроллера вызываем один метод сервиса, который относится к этому модулю.
Уже в сервисе ми работаем с бд черезе репозитории орм-ки (typeorm) и другими сервисами.
Всё вродь неплохо, но меня смущает то, что в методе контроллера юзается только один метод его сервиса, где и происходит вся бизнес-логика.
Что здесь не так? подскажите плиз.
Сервис занимается бизнес логикой. Контроллер получением данных от пользователя и отдачей данных пользователю нужном ему формате , например готовую страницу html, jsonом или же вывод в консоль.
Читайте про solid, grasp.
Читайте про solid, grasp.
AF
Сервис занимается бизнес логикой. Контроллер получением данных от пользователя и отдачей данных пользователю нужном ему формате , например готовую страницу html, jsonом или же вывод в консоль.
Читайте про solid, grasp.
Читайте про solid, grasp.
То, что надо было
AF
Благодарен!