Comments 19
Может быть, вы бы глянули в сторону nLog или log4net? (хотя nLog получше будет). Вот тут как раз--про логгирование в базу.
Может быть, потратили бы чуть больше времени, зато оно с лихвой окупилось бы впоследствии (когда вам понадобилось бы писать еще и в текстовый файл; а в базу, например, писать только warnings and errors).
Может быть, потратили бы чуть больше времени, зато оно с лихвой окупилось бы впоследствии (когда вам понадобилось бы писать еще и в текстовый файл; а в базу, например, писать только warnings and errors).
Видите ли, я в самом начале обратил внимание на то, что времени было в обрез, потому как были более важные части, которые надо было реализовать. А защитить себя хочется. Плюс ко всему так же сразу обратил внимание, что это простейший способ, и он не претендует на универсальность. Но в этом и прелесть. Он простой, реализуется за минимальное количество времени, и при этом частично, но покрывает вопрос логирования.
Естественно, если было бы больше времени, то этот вопрос был бы решен другим способом. Исходя из конкретных задач можно было бы подобрать наиболее удачный метод.
Давайте отвлечемся, и представим себе ситуацию:
Вы берете готовый инструмент. И по тем или иным причинам у Вас начинаются проблемы. Это может быть из-за собственной криворукости, из-за криво установленного ПО, из-за не знания основ работы этого инструмента, из-за использования других инструментов, которые неожиданно начинают конфликтовать, из-за магии, и т.д.
Отрицать возможность наступления такого события – с моей точки зрения не правильно. Думаю, что многие из разработчиков сталкивались с такого рода проблемами. Именно поэтому, обычно закладывают дополнительное время на «всякий случай». Но это я отвлекся.
Итак, чудес не бывает, и рано или поздно, Вы находите, в чем была проблема. Вы сокрушаетесь, ругаете себя/разработчиков ПО/инопланетян/Билла Гейтса/Маму опоссума/ и т.д.
Но при этом Вы потеряли время. Да, инструмент действительно стоящий. Делает невиданные чудеса. Но потратив на это время, Вы просто не успели доделать функциональность.
А теперь вопрос: «Что лучше? Знать, что Вы себя хоть как-то защитили и успели доделать функциональность, и в будущем, когда у Вас будет время, сделать все нормально, или сознательно пойти в сторону риска того, что Вы не успеете доделать функциональность, и поставить вопрос будущего в плохую сторону?»
P.S. Еще раз повторюсь. Этот способ не претендует на универсальность. И не является панацеей. Но в сжатых сроках реализуется быстро, работает и помогает Вам защититься.
Естественно, если было бы больше времени, то этот вопрос был бы решен другим способом. Исходя из конкретных задач можно было бы подобрать наиболее удачный метод.
Давайте отвлечемся, и представим себе ситуацию:
Вы берете готовый инструмент. И по тем или иным причинам у Вас начинаются проблемы. Это может быть из-за собственной криворукости, из-за криво установленного ПО, из-за не знания основ работы этого инструмента, из-за использования других инструментов, которые неожиданно начинают конфликтовать, из-за магии, и т.д.
Отрицать возможность наступления такого события – с моей точки зрения не правильно. Думаю, что многие из разработчиков сталкивались с такого рода проблемами. Именно поэтому, обычно закладывают дополнительное время на «всякий случай». Но это я отвлекся.
Итак, чудес не бывает, и рано или поздно, Вы находите, в чем была проблема. Вы сокрушаетесь, ругаете себя/разработчиков ПО/инопланетян/Билла Гейтса/Маму опоссума/ и т.д.
Но при этом Вы потеряли время. Да, инструмент действительно стоящий. Делает невиданные чудеса. Но потратив на это время, Вы просто не успели доделать функциональность.
А теперь вопрос: «Что лучше? Знать, что Вы себя хоть как-то защитили и успели доделать функциональность, и в будущем, когда у Вас будет время, сделать все нормально, или сознательно пойти в сторону риска того, что Вы не успеете доделать функциональность, и поставить вопрос будущего в плохую сторону?»
P.S. Еще раз повторюсь. Этот способ не претендует на универсальность. И не является панацеей. Но в сжатых сроках реализуется быстро, работает и помогает Вам защититься.
Да, я понимаю ваши аргументы (в основном вы говорите о рисках), но вот несколько моих:
1. Быстрота реализации. Из своего опыта (а также основываясь на стандартных повсеместных рекомендациях типа «не надо изобретать велосипеды»--то есть из опыта других инженеров) я думаю, что прикрутить nLog было бы быстрее, чем писать свой код. Может быть, скопировать ваш код будет теперь быстрее, чем прикрутить nLog с нуля. С другой стороны, если бы вы написали статью о том, как прикрутить nLog, это было бы так же быстро.
2. Риски. Конечно, есть риски в прикручивании nLog, но они малы, потому что это _очень_ популярная библиотека, и на любой подводный камень будет вопрос на stackoverflow. Плюс см. ниже.
3. «нет ничего более постоянного, чем временные решения». Вам приедется не раз сталкиваться с этой функциональностью, и, я думаю, чем раньше вы от нее избавитесь, тем будет лучше. И лучше всего--не писать ее сразу. То есть, на мой взгляд, длительное неудобство перевешивает риски начального этапа, о которых говорите вы.
4. Ваш код плохо решает проблему. Потому что очень много ошибок бывает при работе с базой. И вы о них никогда не узнаете.
5. Все аргументы из коммента ниже :-)
Тем не менее, спасибо за статью!
1. Быстрота реализации. Из своего опыта (а также основываясь на стандартных повсеместных рекомендациях типа «не надо изобретать велосипеды»--то есть из опыта других инженеров) я думаю, что прикрутить nLog было бы быстрее, чем писать свой код. Может быть, скопировать ваш код будет теперь быстрее, чем прикрутить nLog с нуля. С другой стороны, если бы вы написали статью о том, как прикрутить nLog, это было бы так же быстро.
2. Риски. Конечно, есть риски в прикручивании nLog, но они малы, потому что это _очень_ популярная библиотека, и на любой подводный камень будет вопрос на stackoverflow. Плюс см. ниже.
3. «нет ничего более постоянного, чем временные решения». Вам приедется не раз сталкиваться с этой функциональностью, и, я думаю, чем раньше вы от нее избавитесь, тем будет лучше. И лучше всего--не писать ее сразу. То есть, на мой взгляд, длительное неудобство перевешивает риски начального этапа, о которых говорите вы.
4. Ваш код плохо решает проблему. Потому что очень много ошибок бывает при работе с базой. И вы о них никогда не узнаете.
5. Все аргументы из коммента ниже :-)
Тем не менее, спасибо за статью!
Я тоже понимаю Вашу точку зрения. Но это не полноценное решение. Это способ получить функциональность до ее нормальной реализации.
Не относитесь так критично к этому. «Либо все, либо ничего». По мне, так лучше иметь хоть какую-то возможность посмотреть что было, и куда копать, нежели играть в слепого котенка.
Пожалуйста:)
Не относитесь так критично к этому. «Либо все, либо ничего». По мне, так лучше иметь хоть какую-то возможность посмотреть что было, и куда копать, нежели играть в слепого котенка.
Пожалуйста:)
Уверен, когда программисты начнут сначала изучать имеющиеся решения задач, и лишь потом начинать изобретать свои велосипеды (деревянные, без руля, передач, звонка и даже сидения), тогда мир станет чуточку совершенее :)
простите за злую иронию.
простите за злую иронию.
Maxkn
Простите, а Вы работали напрямую с заказчиком от самого начала до самого конца?
Простите, а Вы работали напрямую с заказчиком от самого начала до самого конца?
Простите, а какое это имеет отношение к логгированию?
Как бы странно это не было, но самое, что, ни наесть, прямое.
Если брать абстрактно, то Вы, безусловно, правы. Но есть такая штука как реальность.
Просто подумайте над этим:
Люди почему-то до сих пор покупают российские машины, хотя есть огромное количество веских поводов этого не делать. Но они покупают, и они оказываются правы.
P.S. Попробуйте сами пообщаться с заказчиками, и не с теми, которые «в теме» передовых технологий. И я Вас уверяю, после некоторого числа, Ваши взгляды сильно изменяться.
Если брать абстрактно, то Вы, безусловно, правы. Но есть такая штука как реальность.
Просто подумайте над этим:
Люди почему-то до сих пор покупают российские машины, хотя есть огромное количество веских поводов этого не делать. Но они покупают, и они оказываются правы.
P.S. Попробуйте сами пообщаться с заказчиками, и не с теми, которые «в теме» передовых технологий. И я Вас уверяю, после некоторого числа, Ваши взгляды сильно изменяться.
Если вам хочется себя в этом убедить — ради бога. Мой опыт подсказывает, что заказчику нужно решение его задачи, а какой логгер вы используете ему фиолетово. Это в реальности.
Что касается работоспособности вашего решения попробуйте просто ответить на следующие вопросы.
1. что произойдет, если длина одного из значений формы будет больше 1001 байт или больше?
2. что произойдет, если в вашем супер методе Application_PreRequestHandlerExecute случится эксепшен?
3. как такая реализация логгинга просадит производительность веб-приложения в котором она применяется?
4. как сильно будет расти база данных лога при увеличении нагрузки? как вы планируете по ней чтото искать, если индекс у вас только по id которое никому никуда не уперлось.
5. Что вы запишете в лог, если эксепшен произойдет непосредственно при обработке запроса?
6. Каждый раз, чтобы записать в чтото в лог вам надо создавать объект LogEntry. вы действительно думаете что это удобно? особенно учитывая его жестко заданный формат?
P.S. И да, добро пожаловать в реальность?:)
Что касается работоспособности вашего решения попробуйте просто ответить на следующие вопросы.
1. что произойдет, если длина одного из значений формы будет больше 1001 байт или больше?
2. что произойдет, если в вашем супер методе Application_PreRequestHandlerExecute случится эксепшен?
3. как такая реализация логгинга просадит производительность веб-приложения в котором она применяется?
4. как сильно будет расти база данных лога при увеличении нагрузки? как вы планируете по ней чтото искать, если индекс у вас только по id которое никому никуда не уперлось.
5. Что вы запишете в лог, если эксепшен произойдет непосредственно при обработке запроса?
6. Каждый раз, чтобы записать в чтото в лог вам надо создавать объект LogEntry. вы действительно думаете что это удобно? особенно учитывая его жестко заданный формат?
P.S. И да, добро пожаловать в реальность?:)
Напоминаю, я сразу говорил, что этот метод не претендует на универсальность.
Вы требуете от него универсальности и сверхпроизводительности. Насчет работоспособности – работает.
1. Exception
2. Будет плохо
3. Безусловно согласен – это плохо
4. Расти будет быстро – как бамбук. Если применить логику, то можно найти.
5. Ничего
6. Не особо
Вы путаете понятия «work around» и конечный метод.
Тогда вопрос. А Вы знаете, почему Ferrari плохая машина? На ней мало картошки можно отвезти:)
Ну, честно. Это простое решение. Оно позволяет получить минимальную, НО функциональность. А это, кстати, больше чем 0. :)
Естественно, когда будет на это время, можно будет уже в спокойной и нормальной обстановке просмотреть имеющиеся решения. И выбрать наиболее подходящее с учетом задач.
Кстати, вопрос. А что Вы будете делать, если политика компании будет запрещать использование сторонних библиотек (ну бывает такое, не в моем случае, но все же)?
Вы требуете от него универсальности и сверхпроизводительности. Насчет работоспособности – работает.
1. Exception
2. Будет плохо
3. Безусловно согласен – это плохо
4. Расти будет быстро – как бамбук. Если применить логику, то можно найти.
5. Ничего
6. Не особо
Вы путаете понятия «work around» и конечный метод.
Тогда вопрос. А Вы знаете, почему Ferrari плохая машина? На ней мало картошки можно отвезти:)
Ну, честно. Это простое решение. Оно позволяет получить минимальную, НО функциональность. А это, кстати, больше чем 0. :)
Естественно, когда будет на это время, можно будет уже в спокойной и нормальной обстановке просмотреть имеющиеся решения. И выбрать наиболее подходящее с учетом задач.
Кстати, вопрос. А что Вы будете делать, если политика компании будет запрещать использование сторонних библиотек (ну бывает такое, не в моем случае, но все же)?
Знаете, кажется я понимаю почему у вас проблемы с заказчиками :)
Какие интересные выводы Вы строите:)
Если немного пересказать все выше сказанное:
Идет статья. В ней описывается, что это простой, ни разу не универсальный метод, который минимально и только минимально позволяет прикрыть Вас. Но все же позволяет прикрыть. И реализуется быстро.
И тут же начинается холивар на тему «что это за велосипед?!», «Где броня как у танка?!»
Просто мы с Вами смотрим с разных точек зрения.
Моя задача была быстро сделать минимальное логирование, которое позволит очень быстро разрешить ряд вопросов, если таковые возникнут. Потому что в попыхах выбирать систему логирования — тоже не самый лучший вариант.
Вы же смотрите с точки зрения того, что это должно быть сразу полноценное решение. И понятно, что при такой постановке задач «мое простое решение» — просто грубое вопиющее издевательство!
Это похоже как если бы на «простой способ разжечь костер в лесу» спорить о том, что это не способ для «работы плавильных печей!».
Ну так не нравится, напишите нормально. Так и скажите «он не подойдет как полноценное решение, так как многого нету, да и возможны ошибки при выходе за границы». Но и в тексте ответ, что это «НЕ полноценное решение».
И да, Вам оно не нужно. Так зачем язвить было?
Если немного пересказать все выше сказанное:
Идет статья. В ней описывается, что это простой, ни разу не универсальный метод, который минимально и только минимально позволяет прикрыть Вас. Но все же позволяет прикрыть. И реализуется быстро.
И тут же начинается холивар на тему «что это за велосипед?!», «Где броня как у танка?!»
Просто мы с Вами смотрим с разных точек зрения.
Моя задача была быстро сделать минимальное логирование, которое позволит очень быстро разрешить ряд вопросов, если таковые возникнут. Потому что в попыхах выбирать систему логирования — тоже не самый лучший вариант.
Вы же смотрите с точки зрения того, что это должно быть сразу полноценное решение. И понятно, что при такой постановке задач «мое простое решение» — просто грубое вопиющее издевательство!
Это похоже как если бы на «простой способ разжечь костер в лесу» спорить о том, что это не способ для «работы плавильных печей!».
Ну так не нравится, напишите нормально. Так и скажите «он не подойдет как полноценное решение, так как многого нету, да и возможны ошибки при выходе за границы». Но и в тексте ответ, что это «НЕ полноценное решение».
И да, Вам оно не нужно. Так зачем язвить было?
У вашего простого, легкого, красивого и быстрого решения, наверняка есть масса достоинств, но у него есть один маленький недостаток — оно не решает проблемы логгирования.
Все что вы можете узнать это при каких параметрах запроса случилась проблема. И то, нужно хорошо постараться, чтобы это узнать. Где она случилась и что это за проблема вы не узнаете. Если вы ставили себе именно такую задачу — вы справились блестяще.
Но если вернуться в реальность — вы сами создали себе и, что характерно, заказчику, с которым вы работаете напрямую — бааааальшой геморрой.
Врядли ошибусь, если предположу, что решение вы внедрили вчера-сегодня, думаю первый месяц его полета будет для вас незабываем. Но кто предупрежден, тот вооружен :)
Все что вы можете узнать это при каких параметрах запроса случилась проблема. И то, нужно хорошо постараться, чтобы это узнать. Где она случилась и что это за проблема вы не узнаете. Если вы ставили себе именно такую задачу — вы справились блестяще.
Но если вернуться в реальность — вы сами создали себе и, что характерно, заказчику, с которым вы работаете напрямую — бааааальшой геморрой.
Врядли ошибусь, если предположу, что решение вы внедрили вчера-сегодня, думаю первый месяц его полета будет для вас незабываем. Но кто предупрежден, тот вооружен :)
Сколько в Вас агрессии.
Вы опять пытаетесь сравнить его с большими и многофункциональными средствами.
Как то Вы странно проектируете приложение, если Вы не можете понять при запросах, что происходило.
Геморрой в чем? В том, что есть хоть какая-то возможность понять, что происходило, нежели ее отсутствие?
Решение развивается постепенно, у него нет тех задания. Да вроде, пока все в рабочем порядке. И уже давно, а что?:)
Ладно, давайте прекратим этот бессмысленный спор.
Вы опять пытаетесь сравнить его с большими и многофункциональными средствами.
Как то Вы странно проектируете приложение, если Вы не можете понять при запросах, что происходило.
Геморрой в чем? В том, что есть хоть какая-то возможность понять, что происходило, нежели ее отсутствие?
Решение развивается постепенно, у него нет тех задания. Да вроде, пока все в рабочем порядке. И уже давно, а что?:)
Ладно, давайте прекратим этот бессмысленный спор.
Очень интересный подход. Однако, мне кажется, что он применим лишь для небольших решений.
На мой взгляд, основной проблемой является зависимость количества записей в базе данных от параметров запроса. То есть, устроить DOS-атаку довольно несложно: злоумышленник может посылать небольшое количество длинных запросов. Отправить запрос с большим количеством параметров дешевле, чем добавить запись в базу данных. Следовательно, БД станет весьма уязвимым узким местом системы.
На мой взгляд, основной проблемой является зависимость количества записей в базе данных от параметров запроса. То есть, устроить DOS-атаку довольно несложно: злоумышленник может посылать небольшое количество длинных запросов. Отправить запрос с большим количеством параметров дешевле, чем добавить запись в базу данных. Следовательно, БД станет весьма уязвимым узким местом системы.
Кажется, я забыл описать один важный момент. Приложение предназначено для внутреннего использования. Естественно, на нем нет такой нагрузки как на неплохо посещаемом интеренет-ресурсе. Его задача решать внутренние задачи. Поэтому и можно иногда себя побаловать простыми и легкими решениями.
И за DOS-атаку просто оторвут руки пользователю.
apple_fan
Я с Вами согласен — это совсем не подходящее решение для нагрузочных систем. Я бы немного скорректировал Вас. Это применимо лишь для небольших и внутренних решений. Потому как внутреннее решение может быть сложным, но не требовать выдерживать большие нагрузки.
Denisio
Абсолютно с Вами согласен. В случае нагрузочного решения, наличие такого количества запросов к БД на каждый action — это смертоубийство.
И за DOS-атаку просто оторвут руки пользователю.
apple_fan
Я с Вами согласен — это совсем не подходящее решение для нагрузочных систем. Я бы немного скорректировал Вас. Это применимо лишь для небольших и внутренних решений. Потому как внутреннее решение может быть сложным, но не требовать выдерживать большие нагрузки.
Denisio
Абсолютно с Вами согласен. В случае нагрузочного решения, наличие такого количества запросов к БД на каждый action — это смертоубийство.
Также есть отличное средство Change Data Capture которое быстро включается на sql server 2008(насчет предыдущих версий не знаю есть ли). Это позволит вам включить логированние как для одной таблицы так и для всех. Но все же имхо всегда должны быть также подключены логгеры типа log4net и другие, т.к. если у вас проект выложен где-то то очень удобно читать хорошо написанные логи вместо того чтобы глядеть в базу — это имхо больше прояснит ситуацию.
ssleptsov
Единственно дополнил бы, что это средство работает только на MSSQL 2008 Enterprise Edition. На Standard это функциональность не поддерживается.
>> очень удобно читать хорошо написанные логи вместо того чтобы глядеть в базу
Дело привычки. Мне удобнее быстро написать несколько запросов в БД, и понять картину.
Единственно дополнил бы, что это средство работает только на MSSQL 2008 Enterprise Edition. На Standard это функциональность не поддерживается.
>> очень удобно читать хорошо написанные логи вместо того чтобы глядеть в базу
Дело привычки. Мне удобнее быстро написать несколько запросов в БД, и понять картину.
Sign up to leave a comment.
Логирование .Net MVC 3 за 30 минут