2016-02-26 4 views
1

Я смущен, как вернуть результат из бизнес-уровня. Иногда мне нужно вернуть сообщение, если оно не соответствует критериям. Например:BLL Возвращаемая строка или DTO

public SalesDTO GetSalesByPrescriptionNo(string prescriptionNo) 
{ 
    int count = unitOfWork.SalesRepository.GetNumberOfPrescriptionUsed(prescriptionNo); 
    if (count > 5) 
     // I cannot return string/error information 
     // since the function is return SalesDTO type 
     return "Cannot used anymore"; 

    var sales = unitOfWork.SalesRepository.GetSalesByPrescriptionNo(prescriptionNo); 
    var salesDTO = Mapper.MapToDTO(sales); 
    return salesDTO; 
} 

Основываясь на хорошей реализации ООП/ООД, как я должен обрабатывать несколько результат с BLL?

Спасибо в продвижении.

+2

Выбросить исключение. –

+0

@IlyaChumakov это не ошибка, почему ее следует рассматривать как исключение? это хороший подход? – Willy

ответ

4

Это исключительный случай, когда метод не может доставить ожидаемый результат.

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

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

Исключения, с другой стороны, будут автоматически перемещаться по всем вызовам метода до тех пор, пока они не появятся в заявлении try/catch. Поэтому нет необходимости проверять исключения, если вы действительно не справитесь с этим.

Это не ошибка, почему ее следует рассматривать как исключение? это хороший подход?

Это является исключение. Метод GetSalesByPrescriptionNo указывает, что он будет поставлять продажи. Ничто в названии, контракте, это указывает на то, что он не сможет вернуть продажи в некоторых ситуациях. Следовательно, вызывающий абонент ожидает метод успеха.

Любое имя метод TryGetSalesByPrescriptionNo или исключение.

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

Вы можете сделать что-то вроде:

if (IsPrescriptionActive(prescriptionNo)) 
{ 
    var sales = GetSalesByPrescriptionNo(prescriptionNo); 
    //do something with sales 
} 

IMHO Мне нравится, что лучше:

if (!TryGetSalesByPrescriptionNo(prescriptionNo, out sales)) 
{ 
    //do something with sales 
} 

, потому что вы не можете понять, посмотрев на вызов, почему метод не работает. Это вы можете с первой альтернативой.

Однако, если вы ожидаете, что пользователь ввел действительный номер рецепта (который по-прежнему активен), нет никакой причины использовать дополнительную проверку. Просто используйте:

var sales = GetSalesByPrescriptionNo(prescriptionNo); 
//do something with sales 

Как это действительно исключительный случай в этой ситуации. т. е. если вы используете IsPrescriptionActive, вы скрываете ошибку (поскольку действительная подписка недействительна где-то в дороге).

Резюме

  1. Предписание должно быть подтверждено в пользовательском интерфейсе и подчинялся непосредственно к пользователю.
  2. Если на бизнес-уровне обнаружен недопустимый рецепт, выведите исключение.
+0

Понимаю, я согласен с тем, что «Код становится намного более загроможденным», спасибо за великолепное объяснение. Я не понимаю, что «у вас обычно есть какой-то другой метод», можете ли вы привести пример? – Willy

+0

@Willy: Я обновил ответ. – jgauffin

Смежные вопросы