Недавно я рефакторинг внутренней платформы конфигурации, в основном рефакторинг серверной части платформы, с целью замены оригинальной структуры koa на структуру гнезда. Поковырявшись несколько дней, я потихоньку рефакторил проект, и потихоньку осознал преимущества фреймворка Nest в процессе рефакторинга.
В этой статье будет рассказано о фреймворке Nest и о том, почему мы решили использовать этот фреймворк (о проблемах, возникших в процессе миграции, вы можете прочитать в последующих статьях).
В заголовок,Зачем использовать гнездо для рефакторинга исходного проекта узла?
Структура проекта Nest понятна
Если вы никогда не контактировали с Nest, вы можете совместитьофициальный сайт гнездатак же какfast-nest Проект быстрого старта на основе гнездадля создания первого впечатления.
Как показано на рисунке, это структура каталогов примера проекта официального веб-сайта. Можно обнаружить, что он несколько отличается от нашего традиционного проекта узла. Мы можем видеть модульную тень в структуре каталогов. Сначала идет основная запись main.ts, затем основной модуль app.module.ts и, наконец, модуль cat, смонтированный в приложении.
Это отличается от большинства проектов, с которыми мы сталкивались ранее.Некоторые из проектов узлов, с которыми мы сталкивались ранее, объединяют уровень контроллера в файл маршрутизатора для обработки, а некоторые разделяют несколько файлов маршрутизации, а затем суммируют их. Давайте поговорим о сервисном уровне.В проектах узлов, с которыми я связался, некоторые из них не отделяют сервисный уровень.Все вещи завершаются и возвращаются на уровне контроллера.
Напротив, структура проекта гнезда более интересна. Модуль cat представляет собой независимый каталог на том же уровне, что и app.module. Этот каталог содержит связанные с cat контроллеры, службы и даже соглашения об интерфейсе. Наконец, cat.module.ts выставляется и внедряется в приложение для завершения монтирования .В этом стиле структуры каталогов мы можем четко видеть контекст всего проекта, будь то первый проект или итерация проекта, может быть легко найти точку входа.
отразделение интересовС точки зрения, большинство наших предыдущих структур проекта узла основаны на технических моментах, чтобы разделить наши проблемы, один связан с контроллером, один связан со службой, один связан с соглашением об интерфейсе и так далее. Вложенный проект отделен от бизнес-уровня, а контент, обслуживающий тот же бизнес, составляет модуль и размещается в том же каталоге. Трудно сказать, какая из двух схем разделения лучше, каждая из них имеет свои преимущества и недостатки.Но наши общие услуги поддерживают различные виды бизнеса, так почему бы не подумать о том, чтобы сосредоточиться на бизнесе :)
Nest полностью поддерживает Typescript
Сам Nest разрабатывается с помощью typescript, поэтому после того, как мы инициализируем проект Nest, мы можем напрямую использовать ts для последующей разработки, и нам не нужно выполнять дополнительные операции js для ts.
Поскольку Nest изначально поддерживает функцию машинописного текста,декораторОн прост в использовании, нам нужно только добавить элемент ExperimentDecorators в tsconfig, чтобы использовать декоратор в проекте.
Может все запутаются, просто используйте декоратор, что тут придумывать?
Это начинается с разработки аннотации, которая поставляется с Nest:
Как показано на рисунке, мы можем использовать декоратор для завершения получения параметров запроса.Например, если мы хотим получить элемент в заголовке запроса, мы можем написать это
@Controller('/test')
export class TestController {
@Post('/create')
async createUser(
@Headers('name') name: string,
@Body('id') id: string
) {
// ...
}
}
В приведенном выше контроллере мы/test/createМетод под маршрутом получает заголовок запросаnameзначение, а в теле запросаidЗначение , имеет следующие небольшие преимущества по сравнению с записью без декораторов.
- Объем кода значительно уменьшен, что способствует чистоте кода.
- Параметры, необходимые сервису, понятны с первого взгляда, если мы просто хотим знать, какие параметры нужны сервису, нам нужно только прочитать их в соответствующем контроллере.
- Пользовательский декоратор для получения собственных расширенных параметров запроса
Производительность с открытым исходным кодом и совместимость с проектами
Нетрудно найти в гитхабе Nest, что количество коммитов и решение проблем проекта отличное. Когда мы используем проект с открытым исходным кодом, помимо стабильности самого проекта, мы обычно обращаем внимание на уровень активности проекта, и я думаю, что как коммит, так и проблема могут быть использованы в качестве критерия оценки уровня активности.
Увидев это, некоторые студенты могут спросить, а если есть готовый экспресс-проект, можно ли на него напрямую поставить Nest?
Ответ положительный. Сам Nest должен принадлежать к абстрактной структуре более высокого уровня.Конечно, экспресс может использоваться в нижней части проекта, и Nest также предоставляет соответствующий пакет адаптации.@nestjs/platform-express, после установки зависимостей передайте экспресс-объект в лаунчер Nest во время инициализации, и тогда вы сможете использовать экспресс для развития бизнеса.
конец
Начальное исследование Nest почти завершено.Для автора эта структура дает мне больше чувства регулярности. Это дает проекту чрезвычайно несвязанные и гибкие возможности модуляризации. Это не требует от нас планирования дополнительного набора соглашений. Пока мы его используем, наш проект естественным образом станет модульным проектом. Я считаю, что при последующем использовании мы сможем больше рассказать об использовании Nest и поделиться им с вами.