Mam pytanie jak to jest z tym EF, wzorcem Repositories i Unit of Work. Przeczytałem już kilka artykułów na ten temat i wydaje mi się, że warstwa repozytoriów jest zbędna. Nie chciałbym zagłębiać się w samą implementację tylko skupić na pytaniu czy korzystając z EF, nie ważne czy w wersji 6 czy Core, zasadne jest wprowadzanie repozytoriów i unit of work czy jest to sztuka dla sztuki i tworzenie kolejnej warstwy, która jest realizowana przez EF?
Owszem, jest to zbędne i szkoda tracić czasu. No chyba, że masz na tyle złożoną domenę, że repozytoria wnoszą do niej jakąś wartość.
Raz widziałem, repozytorium gdzie ma to sens, ale każda metoda repo tworzyła dbcontext, robiła savechanges i go niszczyła. Wpisywało się to fajnie
W repozytorium ale ograniczało ef poprzez uniemożliwienie działania unit of work. Odbijało się to czasem na performance.
Performance? Ten kod to zapewne był swoisty performance jakichś wybitnych artystów programistycznych, ale głównym problemem nie była wydajność.
Opisane przez Ciebie podejście to totalna aberracja, bo nie da się w ten sposób zaimplementować transakcji biznesowej. Jej wykonanie wymagałoby zaimplementowania dziwacznej orgii usuwania z bazy uprzednio wstawionych wartości, gdy któraś kolejna transakcja na poziomie repozytorium się nie uda.
Jedyny przypadek, w którym takie podejście by nie przeszkadzało, to CRUD z mapowaniem 1:1 na tabele. Ale w takiej sytuacji nie mamy repozytoriów tylko bieda-DAO.
Repozytoria są dobre, gdy nie chcesz się przywiązywać do ef, np. Część byłaby w dapperze a część w ef.
Do tego nie trzeba repozytoriów. Jeśli nagle zapragnie się zmienić ORM, to i tak trzeba będzie przerobić jakiś kod, jego pierwotne położenie nie ma większego znaczenia.