Który projekt jest najkorzystniejszy: testuj, twórz, tworzyj, przechwytuj?

Question

Załóżmy, że istnieje operacja, która tworzy użytkownika. Ta operacja może zakończyć się niepowodzeniem, jeśli istnieje określony adres e-mail lub nazwa użytkownika. Jeśli się nie udało, trzeba dokładnie wiedzieć, dlaczego. Są trzy podejścia do tego, jak to widzę i zastanawiam się, czy istnieje wyraźny zwycięzca.

Więc oto użytkownik klasa:

class User 
{ 
    public string Email { get; set; } 
    public string UserName { get; set; } 
} 

I są 3 sposoby realizacji operacji tworzenia:

Test-Tworzenie

if (UserExists(user)) act on user exists error; 
if (UsernameExists(user)) act on username exists error; 
CreateUser(user); 

Userexists i UsernameExists sprawiają żądanie db serwer do sprawdzania poprawności. Wywołania te powtarza się ponownie w CreateUser, aby zapewnić prawidłowe korzystanie z interfejsu API. W przypadku niepowodzenia sprawdzania poprawności generuję ArgumentOutOfRangeException w obu przypadkach. Jest więc hit wydajnościowy.

Try-Tworzenie

enum CreateUserResultCode 
{ 
    Success, 
    UserAlreadyExists, 
    UsernameAlreadyExists 
} 

if (!TryCreate(user, out resultCode)) 
{ 
    switch(resultCode) 
    { 
     case UserAlreadyExists: act on user exists error; 
     case UsernameAlreadyExists: act on username exists error; 
    } 
} 

Ten wzór robi walidacji tylko raz, ale uciekać się do korzystania z tzw kody błędów, które nie są uważane za dobrą praktykę.

Create-Złap

try 
{ 
    CreateUser(user); 
} 
catch(UserExistsException) 
{ 
    act on user exists error; 
} 
catch(UsernameExistsException) 
{ 
    act on username exists error; 
} 

nie używam tu kody błędów, ale teraz trzeba utworzyć oddzielną klasę wyjątku dla każdego przypadku. Mniej więcej w tym sensie należy używać wyjątków, ale zastanawiam się, czy warto stworzyć osobny wyjątek zamiast wpisywania.

Czy mamy zatem wyraźnego zwycięzcę, czy raczej kwestię gustu?

Answer 1

Czy mamy zatem wyraźnego zwycięzcę, czy raczej kwestię gustu?

Pierwsza opcja ma podstawową wadę - to nigdy nie będzie bezpieczny wątku lub bezpieczne, jeśli CreateUser polega na zasobach zewnętrznych i inne implementacje mogą tworzyć się między testami. Ogólnie rzecz biorąc, staram się unikać tego "wzoru" z tego powodu.

Podobnie jak w przypadku pozostałych dwóch opcji - tak naprawdę sprowadza się do tego, czy wystąpi awaria: ,. Jeśli oczekuje się, że CreateUser zawodzi w nieco normalny sposób, wzór Try * jest moją preferencją, ponieważ używanie wyjątków zasadniczo powoduje używanie wyjątków do sterowania przepływem.

Jeśli awaria byłaby naprawdę wyjątkowa, wówczas wyjątki byłyby bardziej zrozumiałe.

Answer 2

Test-Create może powodować warunki wyścigu, więc nie jest to świetny pomysł. Prawdopodobnie wykonuje też dodatkową pracę.

Funkcja Try-Create jest dobra, jeśli spodziewasz się, że błędy będą częścią normalnego przepływu kodu (na przykład w przypadku wprowadzania danych przez użytkownika).

Create-Catch jest dobry, jeśli błędy są naprawdę wyjątkowe (więc nie martwisz się o wydajność).

Answer 3

Jest to nieco subiektywne, ale warto wskazać na kilka konkretnych plusów i minusów.

Jedną z wad podejścia do tworzenia testu jest stan wyścigu. Jeśli dwóch klientów spróbuje utworzyć tego samego użytkownika mniej więcej w tym samym czasie, możliwe, że obydwoje przejdą testy, a następnie spróbują utworzyć tego samego użytkownika.

Pomiędzy Try-Create i Create-Catch, wolę Create-Catch, ale to osobisty gust. Można argumentować, że Create-Catch używa wyjątków do sterowania przepływem, które zwykle są mile widziane. Z drugiej strony, Try-Create wymaga nieco kłopotliwego parametru, który można łatwo przeoczyć.

Więc wolę Create-Catch, ale zdecydowanie jest miejsce na debatę.

Answer 4

Podano, że oba UserExists i UsernameExists wykonują połączenia DB. Zakładam, że CreateUser również wywołuje bazę danych.

Dlaczego nie pozwolić, aby baza danych obsługiwała twoje problemy z wątkami? Zakładając, że na twoich tabelach są ustawione odpowiednie ograniczenia, możesz pozwolić, by to się skończyło w ramach zapisanego wywołania proc.

Dlatego oddam swój głos na Create-Catch.