2009-11-08 2 views
6

У меня есть такая логика, как это, прежде чем сохранить запас в db, я проверю наличие в базе данных того же кода запаса в базе данных. Мой вопрос заключается в том, где я должен поместить логику в уровень сервиса или уровень репозитория. вот пример кода:
вариант 1: поместить в слое службы, я поставил метод IsAccountAlreadyExists в слое службы
где поставить логику проверки? В службе или хранилище?

public override void Save(AccountInfo accountInfo) 
{ 
    using (var scope = new TransactionScope()) 
    { 
     if(this.IsAccountAlreadyExists(accountInfo)) 
     { 
      throw new AccountAlreadyExistedException(
       "Account Code : " + accountInfo.AccountCode + 
       " already existed."); 
     } 

     accountRepository.Save(accountInfo); 
      scope.Complete(); 
    } 
} 

вариант 2: я переверну IsAccountAlreadyExists логику слоя хранилища.

public override void Save(AccountInfo accountInfo) 
{ 
    try 
    { 
     using (var scope = new TransactionScope()) 
     { 
      accountRepository.Save(accountInfo); 
      scope.Complete(); 
     } 
    } 
    catch(AccountAlreadyExistedException e) 
    { 
     ... 
    } 
} 

Как вы относитесь к этому?

ответ

2

Поскольку вы просили мнения, вот оно. :-) Поместите логику проверки на самый нижний слой, ближайший к данным. Поэтому в этом случае логика должна быть в Репозитории. Служба может поймать Исключение и перевести его, если захочет. Но критерии, которые «Учетные записи должны быть уникальными», являются признаком Репозитория, ИМО.

0

Я бы поместил его в сервисный слой. Репозиторий обрабатывает логику сохранения.

Ответственность за услугу - обратиться к другим объектам, чтобы выполнить эту работу.

0

Я предпочитаю устанавливать проверки, наиболее близкие к данным - так что в этом случае это будет база данных.

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

Затем я могу поместить чек в слой репозитория в качестве дополнительной меры предосторожности.

5

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

Образец, на который я склонен следить, заключается в том, что уровень хранилища должен быть 99% предназначен для операций чтения-записи-удаления с вашим источником данных. Единственная проверка, которую выполняет мой уровень репозитория, - это очень низкоуровневая проверка на моделях: обычно это делается с помощью метода Model.IsValid. Он проверяет только на обязательные поля и формат/базовый контент этих полей (например, проверка регенерации поля, которое должно быть удержано, и электронной почты). Уровень репозитория не пытается понять эти ошибки - если модель недействительна, то она выдает исключение и заканчивает ее обработку.

Проверка бизнес-логики должна выполняться на служебном уровне. Если объектам пользователя разрешено «назначать» определенную модель («Joe владеет записью X»), сервисный уровень должен выполнить проверки, чтобы гарантировать, что Джо имеет право владеть этой записью и т. Д. Чтобы быть полным, мой уровень сервиса обычно также проверяет метод IsValid на модели, чтобы исключить исключения на уровне данных.

Мой единственный комментарий с вашим примером кода с именем метода «Сохранить» - это слишком неоднозначно. Я предпочитаю создавать/вставлять и обновлять - тогда ясно, что предыдущий приведет к созданию новой записи (в той степени, в которой я перезаписываю поле идентификатора объекта новым значением), в то время как последний должен обновлять запись, и, таким образом, генерирует исключение, если значение Id не передается.

5

Я считаю, что это три уровня (с интерфейсом, определенным для соединения каждой части):

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

Таким образом, если вы решите сохранить свои данные каким-либо другим способом, логика проверки не заблудится.

Аналогичным образом, если вы решили предоставить другую форму доступа к клиенту, вы делаете это без необходимости репликации кучи логики.

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