Меня больше интересовал Node.js в начале прошлого года, и я использовал много фреймворков Node.js, но опыт разработки был не очень хорошим, раньше я переключался с бэкенда на фронтенд, а потом связался с Node. js, поэтому я использовал много серверов.Framework, по сравнению с js, не так просто разработать серверную структуру, и я не хочу использовать машинописный текст (почему бы не использовать java, пожалуйста, не жалуйтесь) а на базе ES6 будет дружелюбнее к новичкам, а дальше сам разрабатывал веб-фреймворк Node.js, и у меня есть время писать статьи (мануальная собачья голова) после Нового года.Поделюсь своим опытом разработки с тобой здесь.
Примечание: оглавление просто для того, чтобы хорошо выглядеть, пишите все, что придет в голову, там вообще нет надписей, мелкий белый текст.
Выбор
Для нижнего слоя фреймворка я думал о разработке собственного набора (слишком высокая стоимость и с учетом экологических проблем), но я отказался от него, затем сравнил Koa2 и Express и, наконец, выбрал Koa2 в качестве нижнего слоя по умолчанию ( наконец, из-за архитектурного дизайна фреймворка в качестве базовой библиотеки можно использовать сервис koa2 или экспресс All 🤣), но в итоге была выбрана интеграция koa2 по умолчанию.
Поскольку выбран koa2, естественно, это экосистема, совместимая с koa2.
Архитектурный дизайн
В начале разработки я фактически пошел по пути коа.Используя коа как нижний слой, я расширил ctx коа.Позже я почувствовал, что инкапсулировать семейное ведро коа казалось бессмысленным.В чем разница между ним и другими фреймворками, пожалуйста, простите мою старомодную идею 🤪), а затем начните думать 🤔: первоначальный замысел и смысл этого фреймворка.
В качестве серверной части я, естественно, думал использовать контейнер IOC в качестве нижнего слоя, чтобы быть более элегантным, но js не имеет ограничений типов, интерфейсов и других функций, и я видел много реализаций машинописного текста (очевидной разницы нет из других back-end фреймворков, а не из Tucao, другие языки полнее и безопаснее), я решил написать js (ES6) версию (низкая стоимость обучения, лучший вход 🤭 настолько самодовольно), а затем я начал свой тур по Node.js.
Неправильно написал. . Ниже описывается архитектура этого фреймворка:
С контейнером в качестве нижнего уровня класс приложения интегрирует базовый класс контейнера и связан с контейнером, являясь объектом приложения и няней контейнера.
Все остальные сервисы (включая koa, router, logger, validate, request, response и т. д.) регистрируются в приложении (фактически привязаны к контейнеру) как провайдеры.
разработка контейнеров
Я не особо задумывался об этом на ранней стадии, и разработка контейнера тоже шла очень гладко.При проектировании режима внедрения зависимостей (потому что не было интерфейса) я хотел избежать многих решений, и в итоге решил использовать декоратор (действительно ароматный), а не ts, используйте черновой декоратор ECMA ( usebabel
транскодирование) и, наконец,1.0
После того, как он будет доработан, он станет дополнительным решением.Декоратор может увеличить опыт разработки, но это не обязательно, и это очень рекомендуемый шаблон для дизайна.
Например, мы открываем конечную точку (маршрут), пример декоратора, а не инъекции:
@Router('users')
class UserController {
@Get()
index() {
// ...
}
}
Этот режим разработан, и приведенный выше пример открываетGET /users
Конечная точка доступа
Что делать, если ввести:
class UserController {
@Config() config;
@Request()
index(request) {
this.request.param()
this.config.get('app.port')
}
}
Мы можем внедрять свойства, методы, конструкторы
Принцип заключается в том, чтобы с помощью декоратора пометить параметры, которые необходимо внедрить, например, метод свойства контроллера, а затем вынуть его из контейнера при вызове функции (здесь есть ямка), т.к.http
Контекст запроса на обслуживание находится в функции обратного вызова, поэтому я привязал функцию обратного вызова к контейнеру.Когда мне нужно получить экземпляр, я передаю контекст в функцию и генерирую, напримерrequest
экземпляр объекта.
провайдер
В фреймворке, разработанном в это время, различные сервисы связаны в контейнере по умолчанию и связаны с классом приложения.Хотя это сервис, который поставляется с фреймворком, он все еще не идеален.Поэтому шаблон проектирования провайдера используется для справки, и все службы извлекаются и проектируются.API для регистрации службы, когда запускается структура, служба по умолчанию регистрируется автоматически.
Таким образом, все наши сервисы полностью отделены от базового ядра фреймворка, что обеспечивает упрощение базового ядра и высокую масштабируемость.
модульный
Поскольку это веб-фреймворк, при использовании он определенно будет нести разные службы, поэтому нам нужно использовать модульные функции для разделения служб для улучшения удобства обслуживания.Например, мы можем установить, какие контроллеры включены в этот модуль (поддерживают подстановочные знаки), какое промежуточное ПО и даже функции подмодуля должны быть загружены для этого модуля
Поэтому я разработал такую схему, используя класс описания модуля для определения модуля.
module.exports = class ExampleModule {
// 标示子模块
modules = [];
// 标示需要装载的控制器
controllers = [];
// 标示需要加载的中间件
middlewares = [];
}
🤓 хорошо
просить
В качестве веб-фреймворка необходимо разобрать запрос или что-то в этом роде, так как это не расширениеctx
свойство, то мое решение состоит в том, чтобы использоватьRequest
класс для разбораctx
, преимущество в том, что я могу разобратьkoa
изctx
,express
изreq
,res
Либо объект контекста других фреймов, а этот класс прописан в контейнере, если у вас есть другие сценарии разрешения, то вы тоже можете прописать сами, а потом для чего хотите (да,IOC
Контейнеры позволяют делать все, что вы хотите 😎).
отклик
Должно быть максимально удобно при выдаче ответа, настолько удобно, чтобы это нужно было делать только в контроллереreturn
Хорошо, даreturn
различных видов, кромеkoa2
Поддерживаемые типы данных в , также поддерживает прямой возврат кадраView
(представление, т.е. шаблон) экземпляр илиResponse
экземпляр (класс ответа) и т. д., платформа будет автоматически оценивать.
class UserController {
index() {
return [{ id: 1 }]
}
}
Это так удобно, конечно мало того, есть более мощные функции.
валидатор
Когда я использую много фреймворков, не очень удобно проверять данные запроса, поэтому я также переделал набор решений (собачья голова),
Конечно, используйте шаблон декоратора
// 定义一个验证类,放在指定目录
class UserPostValidate extends Validate {
@MaxLength(10) username;
@Length(1, 20) password:
}
затем в контроллере
class UserController extends Controller {
store() {
this.request.validate('UserPostValidate')
}
}
голова собаки
Давно пишу, и сначала пойду кушать.На самом деле там много функциональных модулей,таких как лог-сервис,многопроцессный сервис,сервис межпроцессного взаимодействия,сервис связанный с безопасностью,cookie
а такжеsession
Услуги и т.д., если вам интересно, вы можете оставить сообщение, чтобы продолжить отвечать, или опубликовать вторую статью, а в следующий раз выложите некоторые технические ~~🐶
Адрес склада: [Github]
Конечно, основной код фреймворка находится вframework
Этот пакет все еще находится в стадии разработки и тестирования, и некоторые функции и документы оптимизированы.Инструментов относительно мало и их нужно улучшать.Я надеюсь, что есть большие коровы, которые могут развиваться вместе.
теперь прибыл 0.8.x
Версия, прошедшая уже полгода (началась отправка первого npm-пакета), недалеко ушла от первой стабильной версии! ! ! ! В быстром темпе надеемся открыться как можно скорее в следующем году1.0
Версия для публики.
Я также надеюсь, что вы можете попытаться предоставить различные мнения и отзывы.Поскольку в настоящее время он разработан одним человеком,bug
Наверняка много,cli
Инструмент давно не обновлялся.Я готов улучшить инструмент на следующем шаге.Если вам нужно испытать это (если инструмент имеет какие-либоbug
),непосредственныйclone daze
Склад подойдет.
Тогда, надеюсь, каждый не поскупится на своеstar
🐶🐶🐶🐶🐶🐶🐶🐶 Поощрите~~~~~
Наконец, я желаю вам всем счастливого нового года и нового образа в новом году 🎉🎉🎉🎉🎉🎉🎉