Традиционный вход по сравнению с входом AOP

Question

Традиционный вход по сравнению с входом AOP

Я наткнулся на этот (очень старый) вопрос. Интересно, что самое очевидное и изящное решение (imho) отсутствует: Array.prototype.reduce (...) . Все основные браузеры поддерживают эту функцию с 2011 года (IE) или даже раньше (все остальные):

var arr = ['a','b','c','d','d','e','a','b','c','f','g','h','h','h','e','a'];
var map = arr.reduce(function(prev, cur) {
  prev[cur] = (prev[cur] || 0) + 1;
  return prev;
}, {});

// map is an associative array mapping the elements to their frequency:
document.write(JSON.stringify(map));
// prints {"a": 3, "b": 2, "c": 2, "d": 2, "e": 2, "f": 1, "g": 1, "h": 3}

17

aop logging

задан non sequitor 12 October 2009 в 17:48

4 ответа

Я не думаю, что их следует рассматривать как взаимоисключающие альтернативы.

Я думаю, что AOP отлично подходит для трассировки (то есть для входа / выхода из метода регистрации и значений параметров).

Я по-прежнему также использую обычное ведение журнала:

Для сообщений «Информация / Предупреждение / Ошибки»
Для сообщений отладки во время разработки, чтобы увидеть значение определенных переменных или узнать, если, если / затем используется путь и т. д.

10

ответ дан 30 November 2019 в 11:27

Я вполне нашел аспектно-ориентированный подход. Кажется правильным отделить логирование от логики. Я не уверен в производительности, хотя.

Даже если вы решите не использовать AOP, есть лучшие способы ведения журнала, чем это:

if (logger.isDebugEnabled ())

Посмотрите на log4j, который позволит вам изменять уровни журналов, различные приложения и многое другое.

1

ответ дан 30 November 2019 в 11:27

Я согласен с ответом @daxsorbito - и хотел бы продолжить на этом.

Советы по сквозной настройке можно настроить с помощью файлов конфигурации, чтобы вы могли получить другую рекомендацию по ведению журнала производства. Это может улучшить производительность.
AOP Может уменьшить количество кода и побудить разработчиков сосредоточиться на основной задаче.
Много отладки становится проще, если в коде достаточно журналирования. АОП делает его независимым от разработчика. Некоторые разработчики могут не придерживаться дисциплины ведения журнала. Или может чувствовать это ненужным.
Файл журнала содержит согласованные сообщения. (не более "вы говорите картошка, я говорю батата ... :)") - Каждый разработчик может регистрировать это по-своему. Тем не менее, если мы используем AOP-фу, вы можете сделать его единообразным для всего приложения и легко добавить в него много хорошей аналитики.
Это также побуждает вас писать небольшие многократно используемые (и даже лучше, если они иногда тестируемые) методы, которые можно легко отлаживать.
Иногда, это также побудит вас следовать согласованным соглашениям об именах, поскольку это облегчит применение советов для регистрации этих методов во время отладки.

1

ответ дан 30 November 2019 в 11:27

Другие вопросы по тегам:

aop logging

Похожие вопросы:

score 28 · Accepted Answer

Что касается производительности, подход АОП, безусловно, имеет некоторые накладные расходы по сравнению с традиционным.

Одна из многих сильных сторон AOP заключается в том, что она позволяет вам отделить ваши некоммерческие проблемы от бизнес-логики. Это также помогает вам в повседневных задачах, таких как размещение логики логирования в каждом из ваших методов или размещение инструкции try-catch для каждого метода.

Я думаю, что реальная проблема заключается в том, что если снижение производительности (по моему опыту, которое только минимально) компенсирует рутинные задачи, которые вы должны выполнить при разработке.

Один мой друг сказал мне ранее, что лучше иметь более медленное приложение, которое можно обслуживать и масштабировать, чем иметь более быстрое приложение, которое принесет вам ад в обслуживании. Замедление может быть компенсировано многими способами, такими как обновление оборудования и т. Д.

Это всего лишь два моих цента, надеюсь, это поможет.