Witam, tworzę prostą aplikację .NET Core MVC + EF Core.
Struktura Solution podzielona na projekty:
CORE:
-Encje
-DTOs
-Interfejsy
INFRASTRUCTURE:
-Konfiguracje encji
-Migracje
-Klasa Contextu
-Generyczne repo EfRepository<T>
WEB
TESTS
Zastanawiam się co dalej zrobić(1 vs 2 vs 3):
- Czy dla każdej encji mam tworzyć jej własne Repository (z interfejsem metod) i użyć tej abstrakcji w Controllerach projektu WEB? np. By żądać wszystkie osoby z bazy.
- Czy w stworzyć Domain Services dla każdej encji w CORE projektu, gdzie zdefiniuje proste operacje(CRUD w stylu getAll(), getByCondition(), ceate(), ...) dla danej encji. Następnie dodatkowa logika w App Services projektu WEB i dopiero użyć tej abstrakcji w Controllerach WEB?
- Czy po prostu użyć EfRepository<T> bezpośrednio w każdym z Controllerów.
Czym różnią się te podejścia? Docelowo chcę użyć jednej z tych abstrakcji w Controllerach. Jednak nie wiem, które z podejść jest słuszne i czy w ogóle rozumiem wymienione wyżej koncepcje. Czy może mi to ktoś wyjaśnić na przykładach? Zależy mi na czystej architekturze i modułowości aplikacji.