Нарушение бизнес-правила должно выдать исключение?

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

Бизнес-правила не должны выдавать исключение, если они не используются для проверки параметров некоторого API (т.е.: проверка законности запросов) или в модульных тестах (т.е.: бизнес-правила использования для упрощения модульных тестов.NET ).

ошибка на выходе Обычно бизнес-правил и предупреждающие сообщения к объему проверки, все же.

Это действительно зависит от того, что это и где это.

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

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

Это часто - вопрос перспективы и Вашего проектирования приложений.

Usualy я поместил условие в объект Спецификации, который реализует

bool IsVerfiedBy(T entity);

, Таким образом, можно проверить условие без исключения.

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

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

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

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

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

Из-за пути я делаю свою проверку и свое использование LINQtoSQL для ORM, да. Если объект приводит проверку к сбою на бизнес-правиле во время метода OnValidate, единственный способ уведомить, что код вызова должен выдать Исключение. В этом случае я бросаю пользовательский DataValidationException. Используя рычаг метода OnValidate в частичной реализации класса объекта позволяет мне осуществить проверку на, обновляют/вставляют поэтому только допустимые данные, сохраняется к базе данных.

РЕДАКТИРОВАНИЕ я должен прояснить, что обычно делаю проверку ввода данных пользователем в клиенте, таким образом, проверка слоя персистентности является обычно большим количеством страховки и редко, если когда-либо, сбои. Я не обрабатываю клиентскую проверку как исключения, а скорее с условной логикой.

Вы подразумеваете, например, что значение, как предполагается, находится в диапазоне 0-99, но так или иначе закончило тем, что было 105?

, Если это прибывает от пользователя, это - вопрос проверки. Обработано ли это с помощью исключений или не зависит от идиом языка.

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

Во-первых, несколько кавычек из главы 18 Прикладного Программирования Microsoft.NET Framework (страница 402) by Jeffrey Richter :

"Другое распространенное заблуждение - то, что 'исключение' определяет 'ошибку'".

"Исключением является нарушение неявных предположений программного интерфейса".

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

Один хороший пример первой кавычки Richter (исключение! = ошибка), ThreadAbortException. Если Вы называете Ответ. Перенаправление (URL) (в ASP.NET), ThreadAbortException брошен даже при том, что перенаправление успешно выполняется. Почему? Неявное предположение о выполнении страницы ASP.NET - то, что страница выполнится полностью. Ответ. Перенаправление (URL) нарушает это предположение, следовательно исключение.

Это зависит от того, каково бизнес-правило, IMO. Я рисковал бы сказать "не обычно", но я просмотрю его в зависимости от конкретного случая. Я не думаю, что существует любой ответ, поскольку различные бизнес-правила могли бы гарантировать его, в то время как другие не могли бы.

Как альтернативное представление к большинству ответов...

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

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

Так, подводя итог... Это зависит...

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