Услуги BL: исключение или метод Результат? - PullRequest
Новая
       41

Услуги BL: исключение или метод Результат?

3 голосов
/ 21 августа 2011

Как лучше и почему?

V1 

try
{
    var service = IoC.Resolve<IMyBLService>();
    service.Do();
}
catch(BLException ex)
{
   //Handle Exception
}

V2: 

var service = IoC.Resolve<IMyBLService>();
var result = service.Do();
if (!result.Success)
{
   //Handle exception
}

Ответы [ 2 ]

5 голосов
/ 22 августа 2011

Исключения лучше на мой взгляд. Я думаю, что код DDD - это прежде всего хороший объектно-ориентированный код. И дискуссия об использовании исключений и кодов возврата в ОО-языках в основном закончена. В контексте DDD я вижу следующие преимущества использования исключений:

  • они заставляют вызывающий код обрабатывать их. Исключение не позволяет клиентскому коду забыть об ошибке. Телефонный код можно просто забыть проверить на result.Success.

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

  • По моему мнению, DDD - это использование простого языка OO для выражения конкретных проблем бизнеса и максимально возможного исключения инфраструктуры. Создание класса (ов) OperationResult мне кажется слишком инфраструктурным и общим, особенно когда язык уже поддерживает исключения.

  • Доменные объекты будут генерировать исключения в любом случае, даже если это только для проверки аргументов. Поэтому вполне естественно использовать тот же механизм для доменных служб.

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

DDD - это подход, набор руководящих принципов, поэтому не существует «правильного» пути. книга никогда не упоминает эту проблему напрямую, но код в фрагментах и ​​в примере проекта используют исключения.

4 голосов
/ 21 августа 2011

Прежде всего, IoC.Resolve<IMyBLService>() на самом деле очень плохое использование контейнера IoC, вы должны внедрить свои зависимости, а не разрешить их. Я знаю, что дело не в этом, но стоит упомянуть.

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

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

...