Где я должен обрабатывать исключения, в BLL, DAL или PL?

Question

Какое лучшее место для обработки исключений? BLL, DAL или PL?

Должен ли я позволить методам в DAL и BLL генерировать исключения в цепочке и позволить PL обрабатывать их? или я должен обращаться с ними в BLL?

* 1005 например *

Если в моем DAL есть метод, который выдает «ExecuteNonQuery» и обновляет некоторые записи, и по одной или нескольким причинам это влияет на 0 строк. Теперь, как мне сообщить моему PL, что произошло исключение или действительно не было строк, соответствующих этому условию. Должен ли я использовать «try catch» в своем PL-коде и сообщить об этом через исключение, или я должен обработать исключение в DAL и вернуть некоторый специальный код, такой как (-1), чтобы PL различал (исключение) и (нет) строки соответствуют условию, т.е. затронуты ноль строк)?

Answer 1

Нет смысла допускать исключение, которое выдается в пузыре DAL, до PL - как пользователь должен реагировать, если не удалось установить соединение с базой данных?

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

Answer 2

Это огромная тема с множеством ненужных споров (люди с громкими голосами, дающими плохую информацию!) Если вы готовы с этим справиться, следуйте советам s1mm0t, это в основном приемлемо.

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

Редактировать: (уточнение) Вы должны иметь дело с некоторыми ошибками везде - но это не норма «каждая функция». Большую часть времени они позволяют пузырям доходить до PL и обрабатывают глобальную ошибку .NET с помощью собственного кода: регистрируйте полный стек вызовов оттуда с помощью обычной подпрограммы, доступной для всех трех уровней через обработчики событий (см. EDIT внизу сообщения). ). Это означает, что вы не будете пытаться / поймать весь код; только те разделы, которые вы ожидаете, и ошибки, и которые можно обработать прямо здесь, или некритические разделы, с помощью которых вы регистрируете ошибку и информируете пользователя о недоступной функциональности (это еще реже и для сверхнадежных / критических программ)

Кроме того, при работе с элементами с ограниченными ресурсами я часто использую ключевое слово 'using' или try / finally / end try без подвоха. для многопоточных блокировок / мьютексов / флагов предотвращения повторного входа / и т. д. вам также нужно попробовать / наконец во ВСЕХ случаях, чтобы ваша программа все еще работала (особенно приложения с состоянием).

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

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

РЕДАКТИРОВАТЬ: еще одна необходимость хотя бы иметь процедуру регистрации в PL - это будет работать по-разному в зависимости от платформы. Приложение, над которым мы работаем, использует BLL / DAL с версиями 3 PL: версией ASP.Net, версией winforms и версией для регрессивного тестирования в пакетном режиме консольного приложения. Вызываемая подпрограмма регистрации в действительности находится в BLL (DAL только выдает ошибки или полностью обрабатывает все, что получает, или перебрасывает их). Однако это вызывает событие, которое обрабатывается PL; в Интернете он помещает его в журнал сервера и выводит сообщение об ошибке в веб-стиле (дружественное сообщение для производства); в WinForms появляется специальное окно сообщения с информацией о технической поддержке и т. д., которое регистрирует закулисную ошибку (разработчики могут сделать что-то «секретное», чтобы увидеть полную информацию). И, конечно, в тестовой версии это гораздо более простой процесс, но также и другой.
Не уверен, как бы я это сделал в BLL, за исключением передачи параметра «какая платформа», но, поскольку он не включает в себя winforms или asp-библиотеки, от которых зависит ведение журнала, это все равно будет хитростью.

Answer 3

Краткий ответ - это зависит!

Вам следует обрабатывать исключение только в том случае, если вы можете сделать с ним что-то полезное. «Что-то полезное» снова зависит от того, что вы делаете. Возможно, вы захотите записать подробности об исключении, хотя на самом деле это не обрабатывается, и вы должны действительно повторно выдать исключение после регистрации в большинстве случаев. Вы можете захотеть заключить исключение в какое-то другое (возможно, пользовательское) исключение, чтобы добавить дополнительную информацию к исключению. Когда @mbeckish коснется, вы можете попытаться восстановиться после исключения, повторив, например, операцию - однако вы должны быть осторожны, чтобы не повторить попытку навсегда. Наконец (извините за каламбур) вы можете использовать блок finally для очистки любых ресурсов, таких как открытое соединение с БД. То, что вы решите сделать с этим исключением, будет влиять на то, где вы с этим справитесь. Вполне вероятно, что существует не так много полезных вещей, которые можно было бы сделать со многими исключениями, кроме как сообщить пользователю о том, что произошла ошибка, и в этом случае было бы более чем приемлемо обработать исключение на уровне пользовательского интерфейса. и сообщите о проблеме пользователю (вам, вероятно, следует зарегистрировать исключение и далее вниз по слоям).

При создании исключений вы должны создавать исключения только в «исключительных» обстоятельствах, поскольку при создании исключений возникают большие накладные расходы. В своем примере вы предполагаете, что можете подумать о создании исключения, если ваши операции не обновляют записи. Это действительно исключительное? В этой ситуации лучше было бы возвращать количество обновленных записей - это все еще может быть ошибочным условием, о котором необходимо сообщить пользователю, но оно не является исключительным случаем, как при сбое команды, так как соединение с БД имеет упал.

Эта является разумной статьей по обработке исключительных ситуаций.

Answer 4

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

Answer 5

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

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

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

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

Answer 6

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

http://msdn.microsoft.com/en-us/library/ff664698(v=PandP.50).aspx

Потребуется некоторое время, чтобы освоить его, но там много примеров и скринкастов.

Answer 7

Вопрос к вам, где применимо исключение? Если это исключение доступа к данным, его следует перехватить в DAL. Если это логическое исключение, оно должно быть перехвачено в BLL. Если это исключение презентации, то в PL.

Например, если ваш DAL выдает исключение, он должен возвратить ноль или ложь, или что бы то ни было в вашем BLL. Ваш BLL должен знать, что делать, если DAL возвращает ноль, может быть, он проходит через него, может быть, он пытается вызвать другую функцию и т. Д. То же самое происходит с вашим PL, если BLL проходит через нуль из DAL или возвращает что-то конкретное сам по себе уровень представления должен иметь возможность уведомить конечного пользователя о наличии проблемы.

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

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