Предисловие
Использование узла для отдельной модели разработки переднего и заднего коэффициента приносит некоторые преимущества процесса эффективности и разработки, но также сталкивается с многими проблемами. В рамках сложной деловой и технической архитектуры Taobao бэкэнд должен полагаться на Java для создания инфраструктуры и предоставления соответствующих бизнес-интерфейсов для использования фронта. Одной из наиболее важных задач узла во всей среде является прокси, чтобы облегчить интеграцию данных на переднем конце (сторона узла и сторона браузера) для рендеринга страниц. Как сделать хорошую работу в работе агентства, чтобы после передней и задней разработки все еще было легко связано в процессе, это проблема, которую мы должны рассмотреть. В этой статье будет обсуждаться этот вопрос и предлагать решения.
Поскольку бэкэнд обеспечивает множество интерфейсов, разработчики могут также иметь множество способов записи кода на стороне узла для доступа к этим интерфейсам. Если мы не выполним единую обработку архитектуры в методах доступа к интерфейсу и использованию, это приведет к следующим проблемам:
1. Каждый разработчик использует свой собственный стиль кода для написания кода доступа к интерфейсу, вызывая путаницу в каталоге проектов и стиле кодирования, что затрудняет его поддержание.
2. Каждый разработчик пишет свой собственный метод издевательства данных. После завершения разработки ему необходимо вручную изменить код для удаления макета.
3. Чтобы реализовать переключение различных среда интерфейса (ежедневно, предварительно выпущение, онлайн), каждый разработчик может сохранить некоторые файлы конфигурации.
4. Метод вызова интерфейса данных не может быть легко использован различными бизнес -моделями.
5. Соглашение об описании интерфейса данных разбросано в каждом углу кода, что может быть несовместимо с интерфейсными документами, согласованными бэкэндом.
6. После распределения всего проекта стоимость подключения интерфейсов или регрессии тестирования по -прежнему очень высока, и он должен привлекать каждого поставщика интерфейса и пользователя.
Таким образом, мы надеемся иметь такую структуру, которая использует механизм, предоставленный этой структурой для описания всех внешних интерфейсов, зависимых от инженерных проектов, управлять ими единым образом и обеспечить гибкие методы моделирования интерфейса и вызыв, а также удобные методы переключения среды онлайн и производственных средств для беспрепятственного объединения фронтальных и бэк-конечных разработок. ModelProxy - это легкая структура, которая отвечает таким требованиям. Это один из основных компонентов каркаса Midway, а также может использоваться отдельно. Использование ModelProxy может принести следующие преимущества:
1. Различные разработчики имеют единые методы написания кода доступа к интерфейсу, четкое значение и снижение сложности обслуживания.
2. Фреймворк принимает режим Factory + Singleton для реализации множественного мультиплексирования конфигурации интерфейса за один раз. И разработчики могут настроить и собирать свои собственные бизнес -модели (инъекция зависимости).
3. Он может легко переключать онлайн, ежедневные и предварительные условия.
4. Встроенные максимальные двигатели, такие как River-Mock и Mockjs, предоставление фиктивных данных очень удобно.
5. Используйте файлы конфигурации интерфейса для управления интерфейсными описаниями зависимостей, чтобы избежать разброса в различных кодах.
6. Поддерживает совместное использование модели на стороне браузера, которую можно использовать для визуализации данных. Весь прокси -процесс прозрачен для браузера.
7. Сам файл конфигурации интерфейса является структурированным документом описания, и документ может автоматически генерироваться с использованием коллекции реки. Его также можно использовать для тестирования соответствующего интерфейса автоматизации, чтобы сформировать закрытый цикл во всем процессе разработки.
Схема принципа работы моделей и схема процесса разработки
На приведенном выше рисунке разработчик сначала должен описать все зависимости интерфейса бэкэнд в проекте и записать его в файл конфигурации interface.json в соответствии с указанным форматом JSON. При необходимости необходимо записано файл правил для каждого интерфейса, то есть правила интерфейса часть рисунка. Этот файл правил используется для издевания данных на этапе разработки или для использования речного инструмента, установленного для проверки интерфейса на стадии совместной отладки. Содержание файла правила зависит от того, какой максимальный двигатель используется (например, Mockjs, River-Mock и т. Д.). После завершения конфигурации вы можете создать свою собственную бизнес -модель в коде в соответствии с вашими потребностями.
Вот простой пример:
【Пример 1】
Первым шагом является создание интерфейса файла конфигурации интерфейса.
Кода -копия выглядит следующим образом:
{
«Название»: «PAD Taobao Project Data Data Dature Definition»,
"Версия": "1.0.0",
"Двигатель": "Mockjs",
"RuleBase": "./Interfacerules/",
"Статус": "онлайн",
"Интерфейсы": [{
"Имя": "Основной поиск интерфейса",
"id": "search.getItems",
"URLS": {
"Online": "http://smtaobao.com/client/search.do"
}
}]
}
Шаг 2 Создайте и используйте модель в коде
Кода -копия выглядит следующим образом:
// ввести модуль
var modelproxy = require ('modelproxy');
// Глобальная инициализация вводит файлы конфигурации интерфейса (примечание: инициализация работает только один раз)
Modelproxy.init ('./interface.json');
// для получения дополнительной режима создания, пожалуйста, обратитесь к следующей статье
var searchmodel = new ModelProxy ({
SearchItems: 'search.getItems' // Имя метода пользователя: Идентификатор интерфейса, определенный в файле конфигурации
});
// Использование модели, примечание. Параметры, необходимые для вызова метода, являются параметрами, необходимыми для фактического интерфейса.
searchmodel.searchitems ({Q: 'iPhone6'})
//! Обратите внимание, что вы должны вызвать метод выполненного, чтобы указать функцию обратного вызова, чтобы получить данные, полученные, вызывая SearchItems асинхронно выше!
.done (function (data) {
console.log (data);
})
.error (function (err) {
console.log (err);
});
Богатство функций модели Proxy заключается в том, что она поддерживает различные формы профилей для создания бизнес -моделей, которые требуют бизнеса:
Создайте объект, используя идентификатор интерфейса>, получит слово после последнего ». '.' Количество идентификатора в качестве имени метода
Кода -копия выглядит следующим образом:
Modelproxy.create ('search.getitem');
Использовать значение ключа JSON объект> Имя пользовательского метода: идентификатор интерфейса
Кода -копия выглядит следующим образом:
Modelproxy.create ({
GetName: 'session.getUsername',
getMycarts: 'cart.getCarts'
});
Используйте форму массива> Посчи за последнее. номер как имя метода
Имена вызовов метода, сгенерированные в следующем примере: cart_getitem, getItem, предложить, GetName
Кода -копия выглядит следующим образом:
Modelproxy.create (['cart.getitem', 'search.getitem', 'search.suggest', 'session.user.getName']);
Форма префикса> Все идентификаторы интерфейса, которые удовлетворяют префиксу, будут введены в объект, а последняя часть принимается как имя метода
Кода -копия выглядит следующим образом:
Modelproxy.create ('search.*');
В то же время, используя эти модели, вы можете легко реализовать запросы на слияние или запросы на зависимость и рендеринг шаблонов
[Пример 2] Запрос слияния
Кода -копия выглядит следующим образом:
var model = new ModelProxy ('search.*');
// Запрос слияния (приведенный ниже метод модели указан при настройке идентификатора интерфейса, кроме как для выполнения)
model.suggest ({Q: 'nember'})
.list ({Keyword: 'iPhone6'})
.getnav ({key: 'популярная одежда'})
.done (function (data1, data2, data3) {
// Порядок параметров согласуется с порядком вызовов методов
console.log (data1, data2, data3);
});
[Пример 3] Запрос зависимости
Кода -копия выглядит следующим образом:
var model = new ModelProxy ({
getuser: 'session.getuser',
getmyorderlist: 'order.getorder'
});
// сначала получить идентификатор пользователя, а затем получить список заказов на основе идентификационного номера
model.getuser ({sid: 'fdkaldjfgsakls0322yf8'})
.done (function (data) {
var uid = data.uid;
// Вторичный запрос данных зависит от первого полученного идентификационного номера
this.getmoderlist ({id: uid})
.done (function (data) {
console.log (data);
});
});
Кроме того, ModelProxy может использоваться не только на стороне узла, но и на стороне браузера. Просто представьте модель Proxy-client.js, предоставленную официальным пакетом на странице.
[Пример 4] Использование модели Proxy на стороне браузера
Кода -копия выглядит следующим образом:
<!-представил модуль ModelProxy, который сам является стандартным модулем, инкапсулированным Kissy->
<script src = "modelproxy-client.js"> </script>
<script type = "text/javascript">
Kissy.use ("modelproxy", function (s, modelproxy) {
//! Настройте базовый путь, который согласуется с пути перехвата, настроенного на втором этапе!
// И есть глобальная конфигурация и только один раз!
Modelproxy.configbase ('/model/');
// Создать модель
var searchmodel = modelproxy.create ('search.*');
SearchModel
.list ({Q: 'ihpone6'})
.list ({Q: 'Shangchao'})
.suggest ({Q: 'i'})
.getNav ({Q: 'Skateboard'})
.done (function (data1, data2, data3, data4) {
console.log ({
"LIST_IHPONE6": DATA1,
"List_ShockSuit": Data2,
"Предложение_и": data3,
"getNav_skateboard": Data4
});
});
});
</script>
В то же время, ModelProxy может использоваться с Midway-STPL, еще одним основным компонентом Midway, чтобы реализовать полное совместное использование данных, шаблонов и связанных с ним процессов рендеринга в браузере и стороне сервера. Для получения подробных учебных пособий и документации по модели Proxy, перейдите на https://github.com/purejs/modelproxy
Суммировать
ModelProxy существует в виде настроенной легкой структуры, обеспечивающей дружественную модель интерфейса и методы использования, и в то же время решает задачу спецификации использования интерфейса при разделении режимов развития фронта и движения. В течение всего процесса разработки проекта интерфейс всегда должен быть определен и описан один раз, и передовые разработчики могут ссылаться на него. В то же время речный инструмент используется для автоматического генерации документов, формирования контракта с движными разработчиками и проведения связанных автоматизированных тестов, значительно оптимизируя весь процесс разработки программного обеспечения.
【ПРИМЕЧАНИЕ】 Река-это общий термин для подключенных спецификаций интерфейса и связанных с ними инструментов, разработанных Alibaba Group и разработанных Alibaba Group.