Стратегия ведения журнала на стороне клиента

Question

Мне нужно реализовать стратегию ведения журнала для приложения WPF, которое будет запускаться на рабочем столе клиентской части приложения.

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

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

Любой, кто имеет опыт работы с этой проблемойкакие-нибудь хорошие статьи по этому поводу?

Спасибо.

Answer 1

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

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

Я думаю, вы обнаружите, что большинство пользователей не понимаютдаже не смотря на что-либо *.log.