Что вам нужно сделать, так это иметь четкую линию, которая отделяет ваш интерфейс от бэкэнда. Затем все, что нужно фронтенду от бэкенд-команды, будет всесторонне задокументировано.
Скажем, то, что у вас сейчас есть, выглядит примерно так:
app.get('/', function (req, res) {
database.query('select * from user', function (err, result) {
res.render(result);
});
});
Но тогда вы хотите сделать это так:
на сервере пользовательского интерфейса:
app.get('/', function (req, res) {
request('apiServer/user', function (err, result) {
res.render(result);
});
});
на сервере API:
app.get('/user', function (req, res) {
database.query('select * from user', function (err, result) {
res.send(result);
});
});
Это хорошо. Это позволит разделить интерфейс и сервер, но не только логически, но и физически, находясь на разных серверах.
Я считаю, что если они находятся на одном сервере, все будет в порядке. Вместо вышеперечисленного просто разместите их в разных файлах:
в user.js:
exports.getAll = function (cb) {
database.query('select * from user', cb);
};
в server.js:
var user = require('./user');
app.get('/', function (req, res) {
user.getAll(function (err, result) {
res.render(result);
});
});
Почему это лучше, чем ваше решение? Потому что он разделяет касание базы данных и рендеринг данных, а также у него нет дополнительного HTTP-путешествия туда и обратно.
Следуя шаблону MVC, вы помещаете файлы, подобные user.js, в каталог моделей, вы помещаете файлы, подобные server.js, в каталог контроллера. Вы убедитесь, что оба документа задокументированы для разработчиков интерфейса.
Теперь, если ваши фронтенд-разработчики просто собираются внести изменения в пользовательский интерфейс, они просто коснутся файлов HTML. Если они захотят добавить раздел с данными, они прочитают внутреннюю документацию, добавят еще один вызов модели, чтобы получить данные в соответствующем контроллере, который отображает HTML.
Просто убедитесь, что вы все стандартизируете, поэтому, когда появляется что-то новое, программисты в вашей команде могут каким-то образом предсказать, каким будет интерфейс, используйте хороший ORM для тяжелой работы по вызову базы данных. Если использование ORM не является вашим выбором, сделайте хорошие абстракции.
Таким образом, ваше приложение в слоях может быть таким:
Database --> ORM --> Models --> Controllers --> Views(HTML files)
Теперь фронтенд-разработчики работают над правой стороной диаграммы выше. Им нужно знать задокументированный API своей левой стороны только в том случае, если он хорошо абстрагирован, но им не нужно знать, как он работает. Любой, кто работает с контроллерами, должен знать только документированный API их левой стороны, то есть Модели. Вы можете продолжить его до базы данных слева.
Затем на каждом уровне вы можете иметь модульные тесты и интеграционные тесты вплоть до самого начала, чтобы убедиться, что интерфейсы непротиворечивы.
И если у вас большая команда с большой базой кода, убедитесь, что вы всегда сохраняете обратную совместимость в своих интерфейсах, но с предупреждениями в журналах для устаревших вещей. Никогда не пытайтесь что-либо сломать.
person
Farid Nouri Neshat
schedule
26.05.2014
