Automatyczna implementacja repozytoriów

Czy jest możliwość w ASP.NET automatycznej implementacji repozytoriów, tak jak w Springu? Czy jeśli oznaczę interfejs odpowiednią adnotacją (atrybutem?) i odpowiednio ponazywam metody, to framework może jakoś automagicznie mi to repozytorium zaimplementować?

Po pierwsze, to to nie będą repozytoria.
Po drugie, to w Śpringu to też nie są repozytoria.
Po trzecie, to Ty wcale repozytoriów nie potrzebujesz.
Po czwarte, to ORM rozwiązuje Twój problem.

@somekind: Sugerujesz, że repozytoria są zbędne? I czym są repozytoria w Springu?

Tak, są zbędne, o ile nie piszesz zgodnie z DDD: http://commitandrun.pl/2016/05/11/Repozytorium_najbardziej_niepotrzebny_wzorzec_projektowy/
Repozytoria w Springu to jakieś generyczne DAO.

Ale to wszystko trudne... Z tego, co zrozumiałem, to:

• do CRUDów nie należy tworzyć repozytoriów, bo strata czasu, nawet jeśli inne części systemu używają
• generyczne repozytoria są złe - lepiej napisać jakieś klasy abstrakcyjne i rozszerzać je w razie potrzeby
• zamiast pisać po kilkanaście metod filtrujących lepiej napisać metodę przyjmującą obiekt kryterium, ewentualnie dodać osobne metody dla najczęstszych zapytań
• repozytoria nie powinny udostępniać opcji paginacji (gdzie więc ją robić?)
• repozytoria nie powinny zwracać IQueryable (co więc mają zwracać o_O?)

Dobrze zrozumiałem?
I jeszcze: w Springu jest coś takiego jak services, jaki jest ich odpowiednik w ASP.NET?

nobody01 napisał(a):

Ale to wszystko trudne... Z tego, co zrozumiałem, to:

• do CRUDów nie należy tworzyć repozytoriów, bo strata czasu, nawet jeśli inne części systemu używają
• generyczne repozytoria są złe - lepiej napisać jakieś klasy abstrakcyjne i rozszerzać je w razie potrzeby

Po prostu nie ma sensu samemu tworzyć generycznych repozytoriów, bo de facto API każdego ORMa już Ci to zapewnia.

Reszta kwestii dotyczy używania repozytoriów w kontekście DDD:

• zamiast pisać po kilkanaście metod filtrujących lepiej napisać metodę przyjmującą obiekt kryterium, ewentualnie dodać osobne metody dla najczęstszych zapytań

Chodzi o to, że w różnych kontekstach systemu trzeba mieć różne repozytoria.

• repozytoria nie powinny udostępniać opcji paginacji (gdzie więc ją robić?)

W jakiejś klasie, która służy do pobierania danych w postaci stronicowanej. Możesz ją sobie nazwać np. PaginatedDataProvider. Stronicowanie wynika wyłącznie z potrzeb GUI, logika biznesowa nie potrzebuje paginacji, więc nie ma sensu aby repozytoria wspierały taką możliwość.

• repozytoria nie powinny zwracać IQueryable (co więc mają zwracać o_O?)

Obiekty domenowe i ich kolekcje.

I jeszcze: w Springu jest coś takiego jak services, jaki jest ich odpowiednik w ASP.NET?

Nie ma. ASP.NET to framework do tworzenia aplikacji webowych, nie narzuca żadnej konkretnej architektury. Masz wolność w zaprojektowaniu swojej aplikacji i dostosowaniu architektury to złożoności problemu.

@somekind: Dziękuję. Znasz może jakąś książkę/tutorial/blog mówiącą, jak zbudować aplikację zgodnie z dobrymi praktykami? W książce, którą obecnie czytam, repozytoria są pokazane jako wrappery dla ORMa :(

Domyślam się chyba, co to za książka, którą czytasz. :)

Co do materiałów, o które pytasz, to książek nie znam, mogę np. dać takiego linka: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
Blog też warty poczytania (tzn. ja przeczytałem z 5 postów, gość chyba jest niezły, bo na niewielu blogach aż tyle rzeczy przeczytałem), ale nie należy wszystkiego traktować jak wyrocznię, trzeba samemu się zastanowić.
I generalnie trzeba myśleć - jeśli robisz coś i zauważasz, że powielasz jakieś schematy bo tak jest w dokumentacji/tutorialu, ale czujesz, że tak naprawdę niczego Ci to nie daje, a wręcz przeciwnie - tylko powoduje problemy, to po prostu przestań to robić. Bo jeśli robisz coś dlatego, że inni tak od zawsze robią, to uprawiasz kult cargo.

Mnie najbardziej podobały się książki autorów. Rafał Pawlak, Dariusz Woźniak, Adam Freeman. Krótkie, zwięzłe i na temat. ;)