1. Происхождение
(История чисто вымышленная, любое сходство чисто случайное) Легенда гласит, что давным-давно у нас, честолюбивых людей, возникла идея начать свой бизнес, поэтому мы начали свою собственную мечту об открытии бизнеса, но народу не хватило, поэтому все персонажи у Лао-Цзы все сами по себе:
- Roles: PM, DBA, RD, FED, Designer, ...
- Skills: Linux, MySQL, JAVA, JavaScript, HTML, CSS, ...
- Tools: phpmyadmin, photoshop, powerpoint, ...
Используем генератор экспресс-приложений для имитации традиционной разработки (ибо я давно забыл как пишется java, это просто для удобства демонстрации)
$ npm install express-generator -g # 安装 express-generator
$ express progressive # 初始化项目
$ cd progressive # 进入目录
$ npm install # 安装依赖
$ npm start # 启动项目
Затем радостно открываем localhost:3000 и видим нашу страницу:
Тогда я видел исследование код:
Я обнаружил, что мой механизм шаблонов использует jade, который динамически обрабатывается через сервер nodejs:
// app.js
app.set('view engine', 'jade');
Затем, когда я захожу на localhost:3000, начинается рендеринг интерфейса:
// routers/index.js
router.get('/', function(req, res, next) {
// 假设这里我为了获取 title 的值，对 sql 进行了查询，然后把title的值插入到模板引擎中
...
res.render('index', { title: 'Express' });
});
Затем я снова исследовалнефритовый синтаксис, для подготовки к последующей разработке:
// index.jade
extends layout
block content
h1= title
p Welcome to #{title}
Затем мы приступили к дальнейшей разработке.... Через несколько месяцев мы написали sql, написали jade, написали node.... . Делайте PM, делайте DBA, RD... Наконец проект завершен. Тогда я с радостью получил инвестиции инвестора. У меня есть деньги. Я не могу делать все в одиночку в итерации проекта, верно? Я могу найти несколько человек для совместной разработки, поэтому я нанял фронтенд, бэкенд и продакт-менеджера. …
Приятным и счастливым за развитие открытия моего кода:
...... Кто такой WTFперчаткиСтавим в кастрюлю варить...
2. Для лучшего разделения мы начали рефакторить
После обнаружения проблемы, чтобы лучше избавиться от этого фронтенда, сильно зависящего от бэкенда, мы хотим отделить интерфейс уровня данных и взаимодействовать в виде ajax, чтобы сервер отвечал только для логики рендеринга, а не для заполнения данных. Часть данных страницы взаимодействует в форме ajax json, поэтому наша структура может выглядеть так:
Итак, теперь моя логика запроса страницы выглядит так:
// routers/index.js
router.get('/', function(req, res, next) {
res.render('index');
});
router.get('/getTitle', function(req, res, next) {
res.json({
code: 0,
msg: 'success',
data: 'express'
})
});
На странице Новый index.js
ajaxGet('/getTitle', function (err, res) {
$('#title').text('welcome to ' + res.data);
});
Реконструкция index.jade
extends layout
block content
h1= title
p#title
append scripts
script(src='/javascripts/jquery.min.js')
script(src='/javascripts/index.js')
Это завершает проблему внешнего и внутреннего слоев взаимодействия данных. но: внешние и внутренние границы разделены браузерами и серверами. Затем мы часто обнаруживаем некоторые проблемы:
Затем, как фронтенд-разработчики, мы столкнемся со следующими проблемами в реальных сценариях разработки:
- Среда: для локальной разработки вам нужна внутренняя среда, такая как службы nodejs (если вы собираетесь использовать другие языки, нам могут понадобиться tomcat, Apache....), что влияет на эффективность разработки.
- Совместная отладка: передняя и задняя части совместно используют набор серверных сред, и код необходимо синхронизировать во времени, что приводит к низкой эффективности. В то же время фронтенд и бэкенд отличаются друг от друга: фронтенд больше фокусируется на адаптации браузера, отображении эффектов и пользовательском опыте, а сервер — на безопасности и надежности данных...
- интерфейс:
- В определениях интерфейса обычно используются текстовые документы, поэтому во время разработки интерфейса трудно понять поля интерфейса, что влияет на эффективность разработки.
- Изменения интерфейса необходимо переписывать и отправлять повторно, что влияет на эффективность разработки
- Документы разбросаны, что мешает обслуживанию интерфейса
Если что-то влияет на эффективность разработки, значит, проблемы с существующей моделью все еще есть.Очевидно, что идея решения проблем требует от нас переосмысления определения «front-end и back-end».
3. Практика разделения передней и задней частей
Чтобы повысить эффективность разработки, наступила эра внешнего интерфейса MV*:
Front-end и back-end данные взаимодействуют через JSON, который не связан друг с другом, а интерфейсы разделены, back-end предоставляет данные, а front-end делает это сам. Слой МОДЕЛЬ - ОБЪЕКТ JAVASCRIPT, слой ВИД - ШАБЛОН JAVASCRIPT. В отрасли также полно новых решений, таких как: Backbone, EmberJS, KnockoutJS, AngularJS, React, Vue...
Итак, мы начали новое путешествие: одностраничная разработка MVVM:
Мы извлекаем сервисный слой, и окончательная структура каталогов может выглядеть так:
Наш интерфейсный сервер и интерфейс для взаимодействия:
// routers/users.js
let express = require('express');
let router = express.Router();
let usersCtrl = require('../controllers/usersCtrl')
router.post('/login', usersCtrl.login)
router.post('/sign', usersCtrl.sign)
router.get('/getUserInfo', usersCtrl.getUserInfo)
module.exports = router
На данный момент интерфейс использует VUE-CLI для генерации лесов, а возвращенные данные могут быть получены путем установки Axios для запросов данных AJAX. Передние и задние концы не связаны друг с другом.
но: Появляются новые требования. Нам нужно определить внешний и внутренний интерфейсы данных. В настоящее время должен ли внешний интерфейс ждать, пока не будет разработан интерфейс на стороне сервера, прежде чем его можно будет разработать? Как насчет разделения передней и задней части?
В настоящее время внешний интерфейс может принимать форму макета для моделирования данных, а внешний и внутренний интерфейсы должны совместно определять спецификацию интерфейса, поэтому мы с радостью написали множество файлов макетов локально. Однажды интерфейс внезапно изменился на поле, а интерфейс не был вовремя уведомлен.Все закончилось.... Или совместная разработка между членами команды, нам нужно синхронизировать мок-данные, и нам нужно постоянно отправлять git. ... По мере развития проекта сложность возрастает, как управлять фиктивными данными?
На данный момент нам нужен мок сервер, желательно для синхронизации мок интерфейса сервера. Конечно, в Интернете уже есть зрелые решения, такие какeasy-mock. он может хорошо поддержатьSwagger, что является тяжеловесной функцией. Создание всех фиктивных интерфейсов проекта с помощью Swagger занимает всего 1 секунду.
Сказав это, мы завершили базовую схему разделения внешнего и внутреннего интерфейса.Позже я расскажу о проблемах, связанных с приложением nodejs среднего уровня, а также с автоматическим выпуском и формированием шаблонов внешнего интерфейса. Если у вас есть разные мнения по поводу этой статьи, приглашаем к совместному обсуждению.
о:
Автор: Monkeywang
Некоторые изображения и абзацы этой статьи относятся к статье:Разделение интерфейса на практике.Практика разделения фронтенда и бэкенда на Taobao
Подробности смотрите в исходном коде этой статьи:код сервера.интерфейсный код.Скаффолдинг на основе vue и easy-mock
Моя домашняя страница:monkeyWang
Я представлю приложение nodejs среднего уровня и проблемы, связанные с автоматическим выпуском интерфейса и созданием шаблонов, позже, когда будет время. …