Kiedy używać UoW i Repozytoriów generycznych w ASP.NET Core MVC z EF?

0

Zastanawia mnie kiedy w projekcie korzystającym z EF warto zaimplementować UoW i Repozytoria generyczne? Czasami wydaje mi się, że nie ma to większego sensu, dlatego że EF sam w sobie implementuję UoW i repozytoria, czyli pisząc je w naszej aplikacji tworzymy abstrakcje ponad abstrakcją.

1

Jest kilka przypadków, w których ma to sens:

  1. Płacą nam od linijki napisanego kodu.
  2. Programujemy na zasadzie kopiowania miernych tutoriali z internetu.
  3. Jesteśmy całkowicie nieświadomi tego, co robimy.

W pozostałych przypadkach nie ma to żadnego sensu.

3

Wtedy kiedy jest taka potrzeba. Kiedy np. masz aplikacje z rozbudowaną warstwą domeny, stosujesz odpowiedni podział i programowanie do interfejsów- w takiej sytuacji żadne szczegóły implementacji nie dostają się do warstwy domeny, a EF jest takim szczegółem. Inna sprawa że generyczne repozytoria to nie najlepszy pomysł i jest to bardziej sztuka dla sztuki. Repozytoria powinny być konkretne dla typu (chociaż to też zależy od konkretnego przypadku).

0
Aventus napisał(a):

Wtedy kiedy jest taka potrzeba. Kiedy np. masz aplikacje z rozbudowaną warstwą domeny

Jeśli masz rozbudowaną domenę, to potrzebujesz repozytoriów domenowych, a nie generycznych. ;]
Generyczne repozytorium to antywzorzec dla ludzi, którzy pisząc cruda chcą udawać, że mają DDD.

1

Przecież napisałem dalej na temat generycznych repozytoriów... Tylko znów, to wszystko zależy od konkretnego przypadku. Nic nie stoi na przeszkodzie aby mieć generyczne repozytorium "w tle", dostarczające podstawowej funkcjonalności repozytoriom domenowym.

0

Tak, jako jakaś klasa bazowa może sobie być. Tylko po co, jeśli używamy ORMa, który już takiej samej funkcjonalności dostarcza? :)

3

@balti: Jeśli nie widzisz żadnych korzyści to nie używaj generycznej warstwy DAL (jak ktoś lubi formalizmy bo repozytoria to termin z DDD).
Ja mam taki przypadek. CRUD + proste obliczenia w ramach klas, ok 40 klas (tabel) + 15 tabel słownikowych. Od razu wiedziałem, że będą co najmniej 2 różne bazy danych (MySQL + coś normalnego). Pierwszy klient wymusił MySQL-a (mają własnego admina od serwerów, który opiekuje się serwerami i bazami, odpowiada za działanie, backupy itp) a wiedziałem, że będę oferował tę aplikację innym klientom i jeśli będę miał wpływ na wybór bazy to nie wybiorę MySQL-a. Właściwie to wystarczyła by encja na twarz i pchasz.
Wykorzystałem generyczną DAL + EF. Być może NHibernate lepiej to obsługuje ale db context z EF dla MySQL-a musi (chyba) mieć specyficzne anotacje. No i mimo, że prawie cała aplikacja to proste wiązanie tabel do gridów to jakoś podświadomie chciałem mieć jakąś separację db contextu od okienek. Nawet jeśli to sztuczna i nie do końca potrzebna separacja. Dodatkowo aplikacja pokrywa kilka obszarów i każdy obszar miałby i tak własne DBContexty z konfiguracją zakresu tego co jest niezbędne w tych obszarach.
Czy więcej pisania? Być może ale na nieistotnym poziomie.
Zdecydowałem świadomie, że tak chcę to zrobić i drugi raz zrobiłbym tak samo.

1 użytkowników online, w tym zalogowanych: 0, gości: 1