2009-11-08 6 views
6

Mam taką logikę, zanim zapiszę zapas w db, sprawdzę, czy w magazynie znajduje się zapas z tym samym kodem zapasów. Moje pytanie brzmi: gdzie powinienem umieścić logikę, w warstwie usługi lub warstwie repozytorium. oto przykładowy kod:
opcja 1: umieścić w warstwie usług, i umieścić metody IsAccountAlreadyExists w warstwie usług
gdzie umieścić logikę walidacji? W usłudze lub repozytorium?

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(); 
    } 
} 

Opcja 2: poruszę IsAccountAlreadyExists logikę do repozytorium warstwy.

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

jaka jest Twoja opinia?

Odpowiedz

2

Od kiedy poprosiłeś o opinie, oto jest. :-) Ustaw logikę walidacji na najniższej warstwie najbliższej danych. W takim przypadku logika powinna znajdować się w repozytorium. Usługa może złapać wyjątek i przetłumaczyć go, jeśli chce. Ale kryteria "Konta powinny być unikalne" są cechą repozytorium, IMO.

0

Umieściłbym go w warstwie usługi. Repozytorium obsługuje logikę trwałości.

Obowiązkiem użytkownika jest wezwanie innych przedmiotów, aby wykonać zadanie.

0

Preferuję umieszczanie czeków najbliżej danych - w tym przypadku będzie to baza danych.

Wprowadziłbym wyjątkowe ograniczenie w zależności od warunków, które należy spełnić, aby konto nie istniało. Zapewniłoby to, że nikt nie może ominąć mojego średniego poziomu i wstawić złych danych.

Następnie mogę umieścić czek w warstwie repozytorium jako dodatkowy środek ostrożności.

5

Usługa - Wzorce rodów mogą być nieco subiektywne. Oczywiście są tam złe/całkowicie błędne przykłady (ten jeden nie jest jednak), ale częściej niż w rzeczywistości zależy od osobistych preferencji.

Wzór, który mam zamiar śledzić, polega na tym, że warstwa repozytorium powinna w 99% być przeznaczona do operacji odczytu-zapisu i usuwania ze źródłem danych. Jedynym sprawdzeniem poprawności, które wykonuje moja warstwa repozytorium, jest walidacja bardzo niskiego poziomu w modelach: zazwyczaj odbywa się to za pomocą metody Model.IsValid. Sprawdza tylko wymagane pola i format/zawartość podstawową tych pól (np. Sprawdzanie reg-ex pola, które ma przechowywać i e-mail). Warstwa repozytorium nie próbuje nadać sensu tym błędom - jeśli model nie jest prawidłowy, zgłasza wyjątek, który kończy jego obsługę.

Kontrole Business Logic należy wykonywać w Warstwie serwisowej. Jeśli obiekty użytkownika mogą być "przypisane" do określonego Modelu ("Joe posiada rekord X"), warstwa usługi powinna wykonać kontrole, aby upewnić się, że Joe ma prawo do posiadania tego rekordu itp. Aby zakończyć, moja warstwa Usługi ogólnie sprawdza również metodę IsValid w modelu, aby zapobiec wyjątkom warstwy danych.

Mój jedyny komentarz z przykładowym kodem zawiera nazwę metody "Zapisz" - jest to zbyt niejednoznaczne. Preferuję tworzenie/wstawianie i aktualizację - jasne jest, że poprzednia spowoduje utworzenie nowego rekordu (do sporadycznego zakresu, w którym nadpisuję pole identyfikatora obiektu o nową wartość), podczas gdy drugi powinien aktualizować rekord, iw ten sposób wygenerowałby wyjątek, jeśli nie zostanie przekazana żadna wartość Id.

5

że uważa się, że jest trzy poziomy (w interfejs do połączenia zdefiniowanego każdy kawałek):

  • danych w repozytorium - tylko do przechowywania i pobierania danych pierwotnych. Jak mało logiki idzie tutaj, jak to możliwe.
  • Model biznesowy - wszystkie inteligentne urządzenia są tutaj, w tym sprawdzanie poprawności.
  • Usługa (tj. Dostęp klienta) - bardzo cienka część, wystarczająca do zapewnienia połączenia z klientem.

W ten sposób, jeśli zdecydujesz się przechowywać dane w inny sposób, logika walidacji nie zostanie z nimi zgubiona.

Podobnie, jeśli zdecydujesz się na inną formę dostępu klienta, robisz to bez potrzeby powtarzania logiki.