11
Должно ли нарушение бизнес-правила вызывать исключение?Должно ли нарушение бизнес-правила вызывать исключение?
A
ответ
17
Нет. Это часть обычной условной логики обработки в программе (и часто просто замаскированная форма пользовательской ошибки).
+0
, то как вы уведомляете свой пользовательский интерфейс о том, что было нарушено бизнес-правило? особенно в приложениях, где требуется синхронный отклик. например Настольные приложения – devanalyst
7
Это зависит от того, что такое бизнес-правило, ИМО. Я бы рискнул сказать «не обычно», но я бы посмотрел его на индивидуальной основе. Я не думаю, что есть один ответ, так как другие бизнес-правила могут оправдать его, а другие - нет.
3
Из-за того, как я выполняю свою проверку и использую LINQtoSQL для ORM, да. Если сущность не выполняет проверку в бизнес-правиле во время метода OnValidate, единственный способ уведомить вызывающий код - это выбросить исключение. В этом случае я бросаю пользовательское исключение DataValidationException. Использование метода OnValidate в реализации частичного класса объекта позволяет мне принудительно выполнить проверку на обновление/вставку, чтобы только достоверные данные сохранялись в базе данных.
EDIT Я должен четко указать, что я обычно проверяю ввод пользователя на клиенте, поэтому проверка уровня упорства обычно больше страховка и редко, если вообще когда-либо, терпит неудачу. Я не обрабатываю проверку на стороне клиента как исключения, а скорее условную логику.
3
Вы имеете в виду, например, что значение должно находиться в диапазоне 0-99, но каким-то образом получилось 105?
Если это происходит от пользователя, это вопрос проверки. Независимо от того, обрабатывается ли оно с помощью исключений или нет, зависит от идиомы вашего языка.
Если это происходит из вашего хранилища данных, то да, кажется разумным бросить исключение. Это означает, что у вас плохие данные, и вам нужно выяснить, как это произошло, и предотвратить повторение этого события.
0
Отбрасывание исключений может быть интенсивным с вычислительной точки зрения, они находятся за пределами нормы. Например, в .net у вас есть счетчики производительности, которые увеличиваются - это тяжелая ацитивность, а не то, что вы хотели бы сделать, вместо простого условного.
0
Это действительно зависит от того, что это такое и где оно находится.
Если это некоторые данные, поступающие от пользователя, тогда как леванд сказал, что это вопрос проверки. Валидация может оказаться успешной и неудачной, обе ожидаемые варианты с ясными сценариями дальнейших действий.
Если это что-то похожее на ошибки выполнения метода, может возникнуть идея бросить исключение и остановиться прямо перед тем, как сделать больше вреда (например, вызвать несоответствия в базе данных).
Это часто вопрос перспективы и дизайн вашего приложения.
0
Я ставлю обычно работают на жидком состояние в объекте, который реализует спецификации
bool IsVerfiedBy(T entity);
Таким образом, вы можете проверить состояние без исключения.
Если в вашем коде есть место, где спецификация должна быть проверена заранее, вы можете выбросить исключение, потому что это предпосылка вашей функции.
Например, если ваше лицо должно находиться в определенном состоянии до наступления, выведите исключение, если спецификация не будет проверена, но используйте спецификацию до ее сохранения, чтобы исключение не произошло.
1
Я бы сказал не нормально, но я не думаю, что вы можете сказать никогда.
Например, это зависит от того, кто/что обрабатывает неудавшееся правило. Если это пользовательский интерфейс/пользователь, я бы использовал условную логику для надлежащего решения проблемы. Однако, если это ошибка бизнес-правила, например, безликий процесс, который регистрирует любые ошибки в журнале событий, который будет контролироваться техническим ресурсом, тогда исключение может быть как можно более подходящим. В этом более позднем случае соответствующее названное исключение может быть столь же полезно, как хорошо отформатированное сообщение.
2
Как альтернативный взгляд на большинство ответов ...
Это может быть полезно, чтобы бросить исключения из бизнес-логики, в особенности, если они cuased отказом в проверке. Если вы ожидаете объект и получаете нуль, это говорит о том, что некоторая проблема уклонилась от обнаружения в пользовательском интерфейсе (или другом интерфейсе). На данный момент может быть полностью допустимо исключение исключений. В самом деле, вы можете поместить этот тип проверки в бизнес-логику, когда есть несколько интерфейсов.
Отбрасывание исключений на некоторых языках/фреймворках (я думаю, .NET) может быть дорогостоящим, но это не должно вас сразу беспокоить. Это означает, что, по его названию, они используются для исключительных обстоятельств, а не как часть стандартного потока программы. Вы, конечно же, не должны бросать исключение только для выхода из метода. Вы также должны рассмотреть возможность изящного восстановления, где это возможно, что может не включать в себя исключение.
Итак, подводя итог ... Это зависит ...
6
Во-первых, несколько цитат из главы 18 Applied Microsoft .NET Framework Programming (стр 402) по Jeffrey Richter:
" Другим распространенным заблуждением является то, что «исключение» идентифицирует «ошибку».
«Исключение составляет нарушение подразумеваемых предположений программного интерфейса».
Если я правильно выводя из вашего вопроса о том, что нарушение правил бизнеса будет данные, расположенными за пределами определенного диапазона (например), то это ошибка, которую вы могли бы справиться с условным, как «ahockley» предложил , Исходя из определения исключения из Richter, соответствующее использование исключения было бы, если бы ваш код не смог получить бизнес-правило из любого репозитория, который вы используете. Возможность получить бизнес-правило будет разумным подразумеваемым предположением для этого интерфейса, поэтому исключение должно быть выбрано, если это предположение было нарушено.
Одним из хороших примеров первой цитаты Рихтера (исключение! = Ошибка) является исключение ThreadAbortException. Если вы вызываете Response.Redirect (url) (в ASP.NET), генерируется исключение ThreadAbortException, хотя перенаправление успешно завершается. Зачем? Неявное предположение о выполнении страницы ASP.NET заключается в том, что страница будет выполняться полностью. Response.Redirect (url) нарушает это предположение, следовательно исключение.
0
Бизнес-правила не должны вызывать исключение, если только они не используются для проверки параметров некоторого API (например, проверки действительности запроса) или в модульных тестах (то есть: using business rules to simplify .NET unit tests).
Как правило, бизнес-правила выводят сообщения об ошибках и предупреждающие сообщения в область проверки.
3
No Нарушение бизнес-правила - это проблема БИЗНЕСА, в которой исключение является техническим. Нарушение бизнес-правила - это то, что система должна рассматривать как нормальную работу и для которой он должен иметь запрограммированный ответ, а не исключение.
0
Бизнес-правила могут исключать исключение, но они не должны.
Если у вас есть другой способ сообщить информацию об общей и предсказуемой ошибке проверки, вы должны использовать его.
0
Существует хорошее руководство в wiki for the book97 Things Каждый менеджер проекта должен знать, в частности, в главе Distinguish Business Exceptions from Technical.
Итак, если ваш язык программирования поддерживает его, лучше всего создавать пользовательские классы исключений, поэтому их рабочий процесс и обработка могут отличаться от технических исключений.
А? Это не говорит мне все! –
Почему «исключительный» капитализированный? Определить исключительные. – alphadogg
@alphadogg - Я понял, что он означает «нарушает ли бизнес-правило, что ваш слой persistence должен вызывать исключение или вы обрабатываете успех/неудачу с помощью возвращаемых значений». – tvanfosson