Какая информация я должен входить в систему свое веб-приложение?

Идея в том, чтобы не выполнять обновление, если новое значение такое же, как в БД, прямо сейчас

WHERE col1 != @newValue

(очевидно, также должно быть какое-то поле Id для идентификации строки)

WHERE Id = @Id AND col1 != @newValue

PS: Изначально вы хотите обновить, только если значение 'пока', поэтому просто добавьте AND col1 = 'bye', но я чувствую, что это избыточно, я просто полагаю

7
задан Micah 9 June 2009 в 03:59
поделиться

7 ответов

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

Ведение журнала исключений

Когда все остальное терпит неудачу, этого не должно быть. Хорошая идея - иметь центральное средство захвата всех необработанных исключений. Это не должно быть намного сложнее, чем обернуть все ваше приложение гигантским try / catch, если вы не используете больше, чем в потоке. На этом работа не заканчивается хотя, потому что, если вы подождете, пока исключение не достигнет вас, много полезной информации выйдет за рамки. По крайней мере, вы должны попытайтесь собрать определенные части состояния приложения, которые могут помочь в отладке, когда стек раскручивается. Ваше приложение всегда должно быть готово для вывода журнала такого типа, особенно в производственной среде. Не забудьте взглянуть на ELMAH , если вы еще этого не сделали. Я не пробовал, но я слышал замечательные вещи

Журнал приложений

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

Ведение журнала трассировки

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

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

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

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

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

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

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

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

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

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

10
ответ дан 6 December 2019 в 07:28
поделиться

Некоторые вещи для регистрации:

  • бизнес-действия, такие как добавление / удаление элементов. Поговорите с владельцем вашего приложения, чтобы составить список полезных вещей. Это должно иметь смысл для бизнеса, а не для вас (например: когда пользователь отправил отчет, когда пользователь создает новый процесс и т. Д.)
  • исключения
  • исключения
  • исключения

Некоторые вещи, которые НЕ следует регистрировать :

  • не регистрируют информацию просто для отслеживания использования пользователем. Используйте для этого инструмент аналитики (который отслеживает клиента в javascirpt, а не в клиенте)
  • не отслеживает пароли или хеши паролей (огромная проблема безопасности)
4
ответ дан 6 December 2019 в 07:28
поделиться

Возможно, вам следует регистрировать обращения к страницам / ресурсам, которые еще не определены в вашем приложении, но запрашиваются клиентами. Так вы сможете найти уязвимости.

3
ответ дан 6 December 2019 в 07:28
поделиться

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

Наличие уровня журнала и иерархии журнала может помочь в таких ситуациях, потому что вы можете динамически повышать уровень журнала. См. Документацию log4j и log4net .

Наличие уровня журнала и иерархии журнала может помочь в таких ситуациях, потому что вы можете динамически повышать уровень журнала. См. Документацию log4j и log4net .

2
ответ дан 6 December 2019 в 07:28
поделиться

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

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

2
ответ дан 6 December 2019 в 07:28
поделиться

Мои несколько центов. Помимо правильного использования важности журнала и исключений, рассмотрите возможность структурирования операторов журнала, чтобы вы могли легко просматривать данные журнала в будущем. Например - быстрое извлечение значимой информации, выполнение запросов и т. Д. Нет проблем с генерацией океана данных журнала, проблема в том, чтобы преобразовать эти данные в информацию. Таким образом, его предварительное структурирование и определение помогает в дальнейшем использовании. Если вы используете log4j, я бы также предложил использовать сопоставленный диагностический контекст (MDC) - это очень помогает для отслеживания контекстов сеанса. Помимо трассировки и информации, я бы также использовал уровень отладки, на котором обычно сохраняю temp. Предметы. Их можно было отфильтровать или отключить, когда они не нужны.

2
ответ дан 6 December 2019 в 07:28
поделиться

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

1
ответ дан 6 December 2019 в 07:28
поделиться
Другие вопросы по тегам:

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