[M.....v]

#programowanie #designpatterns
Radosław Maziarka - Wzorzec Repository – kilka słów przeciwko

Co myślicie? W sumie dalej uważam, że łatwiej wstrzyknąć repozytorium niż wstrzykiwać lokalną bazę.
Ale rzeczywiście jest dużo problemów z użyciem różnych repozytoriów i łączeniem tabel.
Zastąpiliście jakoś wzorzec repozytorium?
Co się sprawdza u was?

[japer]

@Maav: Wzorzec Repozytorium ciężko zastąpić, kiedy robimy przykładowo jakiś mocking. Zawsze tworzenie interfejsów daje modularność oprogramowania. Repozytorium jest trochę bottleneckiem, bo wymaga tworzenie wielu metod i wychodzi z tego interfejs-mastodont. Trzeba uważać z repozytorium i starać się nie robić za dużo w niej logiki, metody mają być proste i przejrzyste.

[M.....v]

@japer: W artykule jest wskazany np. wzorzec QueryObject, który możnaby mockować.

Ale dla mnie to zmiana z jednego repozytorium z wieloma metodami na wiele klas z jedną metodą.
I możesz je wstrzykiwać, mockować, nie łamią SRP, są małe i łatwo utrzymywalne.

Ale jest ich milion i ciężko będzie znaleźć to, z czego chcemy korzystać.

[japer]

@Maav: Są dwie szkoły interfejsów. Grube, albo cienkie. I to zależy od głównie założeń twórcy, nic więcej. :D
Wolałbym pierdyliard małych obiektów, niż duże i ociężałe.

[markaron]

@Maav: Zgadzam się w 100%. Historycznie Repository miał ukrywać szczegóły implementacyjne silnika bazy danych, tak by kod biznesowy był wolny od jakiejkolwiek infrastruktury. W czasach gdy ORMy na dobre zagościły w aplikacjach biznesowych, wzorzec Repository traci sens, gdyż ich rolę przejęły ORMy. Oprócz tego ORMy implementują wzorzec Unit of Work.

Jedynym przypadkiem w którym bym widział użycie Repository to abstrakcja samej biblioteki orm.

@japer Jezeli chcesz mockować dostęp do

[MacDada]

@Maav: @markaron: Zapominacie o podstawowej rzeczy: repozytorium nie ma nas oddzielić od ORMa. Nie ma nas oddzielić od bazy. Ono ma nas oddzielić od persystencji.

Kto powiedział, że dane muszą być zapisywane w bazie?

Budujesz warstwę modelu. Potrzebujesz gdzieś przechowywać obiekty. Nie interesuje Cię na na razie gdzie, bo to szczegół techniczny, a

[markaron]

@MacDada:

Dlatego też napisałem, że jedynym przypadkiem gdzie widziałbym Repository jest abstrakcja samego ORMa.

Osobiście nie jestem fanem Repository, ale jestem świadom przypadków użycia w których ma on zastosowanie.
Przykładowo w projektach budowanych w oparciu o architekturę cebulową (Onion), czy projekt korzystający z dobroci DDD - gdzie skupiamy się na wyizolowaniu modelu biznesowego od reszty aplikacji w

[M.....v]

@MacDada: Raczej zgadzam się z tym, co napisałeś, jeśli chodzi o abstrakcję nad ORMem.

Rozumiem, że jeśli ktoś tworzy projekt i wie, że nie będzie zmieniał bazy, potrzebuje szybkiego modelowania danych (czy to Code First czy DBFirst), to może wykorzystać ORM w projekcie w logice biznesowej, wykorzysta lokalną bazę do testów czy nawet zamockuje DBSety i nie musi się za bardzo niczym przejmować. Jesteśmy developerami, powinniśmy dobierać odpowiednie narzędzia do projektu

[MacDada]

https://www.youtube.com/watch?v=WpkDN78P884

[markaron]

@MacDada: Dzięki za info, ale zdania co do repozytorium nie zmienię :) Na temat wzorca Repository było pisane wiele i ilu programistów tyle opinii.

Ale jak mówimy o „normalnych” appkach, trochę bardziej skomplikowanych, z potencjałem zakresu życia przez lata, to uzależnianie się od infrastruktury jest podstawowym błędem.

Otóż nie prawda. Jeden z systemów który rozwijamy ma już z 8 lat i wyobraź sobie, że tam nie ma Repository, jest DAL,

[M.....v]

@MacDada: Ale ty w tym momencie wiążesz DAL/ warstwę zapisu do danych/ mechanizm persystencji od razu z Repository. A Repository jest wzorcem, który przy skomplikowanej logice się nie sprawdza.

I Twój przykład wg mnie dobrze to oddaje:

Przykład z realnej appki przy której

[MacDada]

> Ale jak mówimy o „normalnych” appkach, trochę bardziej skomplikowanych, z potencjałem zakresu życia przez lata, to uzależnianie się od infrastruktury jest podstawowym błędem.

Otóż nie prawda. Jeden z systemów który rozwijamy ma już z 8 lat i wyobraź sobie, że tam nie ma Repository, jest DAL, ale nie w formie Repository i działa. W swojej pracy zawodowej widziałem wiele systemów i uwierz mi, uzależnienie się od infrastruktury to najmniejszy problem.

@markaron

[markaron]

@MacDada:

To, że rozwijacie system od 8-u lat i nie ma on Repository nie oznacza, że Wasz kod musi nie działać. Nie mówimy o tym „czy działa” tylko wchodzimy na poziom wyżej, oceniamy jakość kodu (a do tego „działanie” jest podstawą, a potem pojawiają się kolejne czynniki oceny: w tym potencjał zmiany, SOLID, itp.).

Doskonale rozumiem dbałość o jakość kodu (sam jestem tego wielkim orędownikiem) i wartość dodaną jaką Repository