Walki z DDD ciąg dalszy. Potrzebuję klasy czytającej produkty z bazy danych. Ponieważ wykorzystanie repozytoriów nie byłoby wydajne (załóżmy, że tak jest, poza tym już chyba wolę SQLa pisać niż wstrzykiwać 5 repozytoriów i potem jakoś na około budować z tych encji DTO), więc nie mogę jej utworzyć w projekcie Application
. Dlatego w tym projekcie utworzyłem jedynie interfejs IProductReader
, który zawiera deklaracje metod o sygnaturach typu Page<ProductItem> GetProductPage(SearchProductsModel model)
, a implementację planuję dać w Infrastructure
(tam mogę używać EFC albo Dappera). Tylko że infrastruktura nie powinna wiedzieć o czymś takim jak DTO albo ViewModel (a może może wiedzieć?). Ponadto widziałem w kilku artykułach, jak ludzie tworzyli te SQLe w Application
, jednak to sprawia, że zaciera się podział na warstwy. Co zrobić, jeśli już się uparłem na DDD (powtarzam, że to projekt do nauki)?
0
2
Teraz nie walczysz z DDD tylko z CQRS :).
Też należe do grupy trzymającej Readery a warstwie aplikacji, ale nie widzę problemu z odwróceniem zależności: czyli interfejs w warstwie aplikacji, a implementacja w warstwie infrastruktury. Jedno i drugie podejście jest dobre.
Pamiętaj tylko o tym że jak masz jakiegoś ORM, to SQL używają tylko w ostateczności do odczytów, wtedy kiedy sobie ORM nie radzi, nie rób wszystkich odczytów za pomocą SQL.
ORM jest znacznie łatwiejszy w utrzymaniu od SQL.