Сколько проверки нужно сделать? - (простая функция jQuery Log вызывает философские споры) - PullRequest
Новая
       0

Сколько проверки нужно сделать? - (простая функция jQuery Log вызывает философские споры)

0 голосов
/ 25 апреля 2011

Я создал простую функцию jQuery, которая будет использоваться для регистрации событий и ошибок разработчиков ... она вызывает функцию веб-службы, которая просто записывает несколько переданных параметров в таблицу журналов с именем EventLog .

Один из параметров ( logEventStr ) - это просто строка, которая квалифицирует событие журнала ... как 'debug', 'error', 'user', 'info' ... и так далее. У меня есть все эти типы событий в другой таблице, они называются EventTypes , индексируются (то есть 1 = отладка, 2 = информация, 3 = пользователь ...) и связаны через ограничение внешнего ключа со столбцом eventId. таблица журнала.

Итак, во время проверки кода было предложено / утверждено, что следует использовать некоторую первоначальную проверку этой строки события журнала, поскольку «разработчик может ошибочно ввести тип события в параметре logEventStr ». Я объяснил, что у меня есть код в веб-сервисе, который проверяет допустимую строку события и выдает исключение, которое обрабатывается в событии сбоя вызова Ajax ... он даже выводит ошибку имени события с ошибкой в ​​консоль, поэтому Разработчик сразу узнает, что он все испортил и исправит это. В дальнейших «обсуждениях» говорилось, что индексы в EventTypes должны быть жестко закодированы (вероятно, объект JSON) в javascript и проверены перед выполнением вызова веб-службы. Это просто показалось мне глупым, поскольку теперь разработчикам придется следить за изменениями в таблице EventTypes и синхронизировать их вручную с жестко закодированным объектом JSON. Наконец, я несколько смягчился, чтобы заполнить объект JSON еще одним вызовом веб-службы, который возвращает содержимое таблицы EventTypes и кэширует ее, так что это будет одноразовый вызов при первом обращении. Однако я все еще думаю, что даже это не является необходимым ... функция ведения журнала должна использоваться только разработчиком, и конечный пользователь никогда не будет диктовать logEventStr .

Мой вопрос ... какая техника подходит? Сколько проверки должно потребоваться для чего-то такого простого и простого, как функция регистрации, которая должна использоваться исключительно разработчиками?

Я размышлял об этом в выходные, и это все еще беспокоит меня. Конечно, возможно, ни один из них не является правильным подходом, поэтому альтернативные идеи приветствуются.

1 Ответ

1 голос
/ 25 апреля 2011

Почему бы не создать функцию-оболочку для каждого типа событий журнала?

Если ваша исходная функция log и используется так: 

log("user", "is a zombie");

, это можно переписать как: 

logUser("is a zombie");

, где logUser просто вызывает log с параметром user.

Еще один путь - сделать log объектом с различными функциями, поэтомувы можете использовать его следующим образом: 

log.user("is a zombie");

и т. д.

Разработчики, использующие ваш механизм ведения журнала, не должны беспокоиться о его внутренностях, так как мы имеем дело с системой ведения журнала здесьСуществует ограниченное количество типов журналирования, поэтому, если вы заранее представите хорошо продуманный список типов журналирования, которые существуют в базе данных и не нуждаются в изменении, тогда не должно быть беспокойства о том, что что-то может произойти в будущем..

Редактировать (на основе комментария):

Из вашего вопроса я вижу две таблицы, EventLog и EventTypes.Я предполагаю, что EventLog имеет два столбца:

  • eventId
  • event,

, в то время как EventTypes также имеет два столбца:

  • eventId
  • eventDescription.

Этот кусочек информации озадачивает меня, и я цитирую:

теперь разработчики должны идти в ногус изменениями в таблице EventLog

Насколько я понимаю, целью этой таблицы является хранение информации о различных событиях и их типах.Эта таблица будет меняться в том смысле, что строки будут добавляться каждый раз, когда регистрируется событие.Здесь нет структурных изменений.

Таблица EventTypes может измениться, а также добавить новые типы событий.Это также означает, что строка может быть добавлена.

Обе таблицы не будут изменены таким образом, что их столбцы будут добавлены или удалены.

EventTypes более или менее "исправлено"и каждый тип события связан с числом.Этот номер должен быть «соглашением» между вашей базой данных и вашим Javascript.

Итак, если у вас есть три строки, подобные этой:

  • 1 |отладка
  • 2 |информация
  • 3 |user

тогда у вас также должно быть три функции, подобные этой:

  • log.debug
  • log.info
  • log.user

и каждый из них должен позвонить в ваш веб-сервис с соответствующим номером.Это ваше соглашение.

Если добавлен новый тип события, теперь у вашей таблицы есть новая строка, подобная этой:

  • 4 |ошибка

, затем вы должны добавить новую функцию для ваших разработчиков:

  • log.error

Таким образом, нет "взлома"изменения ", так как добавлен новый функционал и ничего старого не сломано в процессе.Предполагая, что ваша схема нумерации не меняется.

Вы просто говорите своим разработчикам «у вас теперь есть новая функция, все остальное будет работать так же, как раньше», и вы продолжаете свой бизнес.

...