Я недавно жаловался. Все знают, что веб-фронт стал очень тяжелым по сравнению с несколькими годами назад. Различные фреймворки JS, различные объекты и многие проекты, публичные модули будут извлечены.
Дисплей пользовательского интерфейса этих модулей одинаков, и разница - фоновая логика. Например, когда мы ведем бизнес в корпоративных путешествиях, у нас обычно есть общественный модуль JS Центра затрат. Клиенты заполняют этот центр затрат при бронировании воздушных билетов. Этот центр затрат распределен в резервации, например, онлайн, офлайн и приложение, что также удобно для ежемесячного урегулирования с компанией -клиентом на более позднем этапе.
Мы также знаем, что после того, как проект становится больше, сложным и SOA, возникает много проблем. Так же, как теория в Интернете, все передовые данные не надежны, поэтому интерфейсные данные другой команды не одинаковы. Когда проект был молодым, он не был настолько неуверенным в себе, и он будет записывать журналы только при логических ошибках. Нормальные бизнес -процессы, как правило, редко записываются. В конце концов, журналы информации выглядят неприглядно, и он также потребляет пропускную способность сервера, а также перетаскивает производительность Интернета.
Но проект большой. Когда вы сталкиваетесь с странной ошибкой в проекте однажды, вы полагаетесь на неполные журналы и, наконец, проследите интерфейсную линию за линией невооруженным глазом. Тем не менее, слишком много параметров, и невозможно точно восстановить данные параметра интерфейса. Тем не менее, вы на 100% уверены, что это определенно проблема возврата интерфейса, но вы не можете получить полное сообщение. В настоящее время вы не можете найти поставщика интерфейса. Я был беспомощен в то время. Было бы здорово, если бы вы думали, что было бы лучше ввести в систему в каждой строке.
После изучения урока, тенденция журналов процессов записи становилась все более и более популярной, и в конечном итоге также было вызвано главным событием в начале года. Я много сказал в замешательстве, что веб-бэкэнд такой, так что разве нам не нужно записывать журналы в текущем фронте? Мы знаем, что, поскольку это публичный модуль JS, этот модуль должен был инкапсулировать некоторые методы самостоятельно, и абсолютно невозможно позволить сторонним программам эксплуатировать свои собственные текстовые узлы, такие как следующие:
Кода -копия выглядит следующим образом:
<!-Третий модуль->
Компания: <input type = "text" id = "company" value = "XXX Co., Ltd." />
Имя сотрудника: <input type = "text" id = "username" value = "Zhang San" />
<!-->
<script type = "text/javascript">
// Центр затрат
var stostcenter = (function () {
var company = (document.getElementById ("Компания") || "") && document.getElementById ("Компания"). Value;
var username = (document.getElementbyid ("username") || "") && document.getElementByid ("username"). Value;
var result = {
getInfo: function () {
return {Компания: Компания, имя пользователя: имя пользователя};
},
валидация: function () {
return boolean (компания && username);
}
};
результат возврата;
}) ();
</script>
Чтобы упростить операции, сторонний пользовательский интерфейс предоставляет узлы пользовательского интерфейса для названий компаний и имен сотрудников и инкапсулирует класс Costenter для предоставления методов чтения. Видно, что моя запланированная программа должна только читать costcenter.getinfo, которая также играет роль в инкапсуляции.
Но проблема возникает здесь. В фактическом проекте значение не может быть получено в Костентере по разным причинам. Конечно, это также может быть общим пользовательским интерфейсом.
Но в то время вы не были уверены, было ли значение фактически получено, но логически, даже если значение не было получено, в принципе вы не могли предотвратить подачу порядка. Поэтому, чтобы тщательно отслеживать ошибку, вы написали класс LogCenter Singleton для записи журнала. Обычно этот способ использовать JS для записи журналов.
<1> ajax
Об этом методе легко придумать, но если вы используете Native Xmlhttprequest, вам необходимо рассмотреть совместимость с браузером. Однако, если вам не нужен местный, вам нужно полагаться на сторонние рамки, такие как jQuery. Однако, в конце концов, есть еще много компаний, которые не используют jQuery, поэтому это необходимо использовать в соответствии с фактическими потребностями.
Кода -копия выглядит следующим образом:
// log center
var logCenter = (function () {
var result = {
Информация: функция (заголовок, сообщение) {
// операция Ajax
$ .get ("http://xxx.com", {"title": title "Message": message}, function () {
}, "почта");
}
};
результат возврата;
}) ();
<2> Изображение
В нашем DOM есть объект, называемый изображением, поэтому мы можем динамически назначить его SRC с целью запроса фонового URL, и в то же время нам нужно передать информацию о заголовке и сообщении в URL. Этот динамический способ к Image.SRC не должен рассматривать проблемы совместимости браузера, что очень хорошо.
Кода -копия выглядит следующим образом:
// log center
var logCenter = (function () {
var result = {
Информация: функция (заголовок, сообщение) {
// операция Ajax
$ .get ("http://xxx.com", {"title": title "Message": message}, function () {
}, "почта");
},
info_image: function (заголовок, сообщение) {
//изображение
var img = новое изображение ();
img.src = "http://www.baidu.com?title=" + title + "& message =" + message + "& temp =" + (math.random () * 100000);
}
};
результат возврата;
}) ();
Приведенное выше основное содержание этой статьи, и мы продолжим подробно обсуждать ее в будущем