Dużo osób pisze o tym, że dla EF nie potrzebujemy repository/unit of work pattern, a co w przypadku podmiany ORMa? Czy korzystanie z tych wzorców ma jakiś negatywny wpływ na wydajność naszej aplikacji? Stosujecie czy nie stosujecie, jakie jest wasze zdanie na ten temat i jak to wygląda u was w pracy? #csharp #programowanie
@Mazowia: przecież EF ma pod spodem UoW. Repository z kolei to kwestia sporna. IMO warto mieć taką warstwę - łatwiej się testuje, masz interfejs (kontrakt) więc wiesz co trzeba zaimplementować w przypadku zmiany EF na coś innego.
@Mazowia: 1. W przypadku CRUDów ma to sens, w przypadku większych agregatów raczej nie. 2. W przypadku CQRSa moje komendy i query są zwykle na tyle skomplikowane, że zmiana ORMa spowoduje również zmiany w zapytaniach. 3. W całej karierze nie zmieniłem ORMa, bo tak. Zdarzały się zmiany bazy np. na nierelacyjną z relacyjnej i vice-versa (Ale co za tym idzie zmieniła się również struktura danych i trzeba było przepisać zapytania itd)
@Mazowia: Chciałbym zobaczyć sensowny use case zmiany ORMa. To brzmi jak pięknie brzmiąca teoria bez pokrycia w praktycznym problemie, szczególnie, że sama podmiana bibliotek w takim przypadku będzie najmniejszym problemem (zobacz sobie, jak wyglądałoby takie same zapytanie dla EF Core'a i np. dla Dappera, a zrozumiesz, że dodatkowa abstrakcja nad tym nic nie zmieni). Repozytorium jako wzorzec wywodzi się z modelowania domenowego i #!$%@? go na partyzanta do CRUDów razem z
@Mazowia: Jakbyś utworzył sobie warstwę abstrakcji nad EF według tych wzorców to przy zmianie ORMa efekt byłby zapewne taki że musiałbyś kod korzystający z tej abstrakcji przepisywać ze względów wydajnościowych stąd jak dla mnie nie ma to żadnego sensu. Warstwą abtrakcji korzystającą z EF powinien być albo service albo command/query
@Czesiowcy: @Myrten: Nigdy nie przejechaliście się na teście, który w pamięci lub sqlite nie wykazał błędu, a w testach integracyjnych już tak? Nie chodzi mi o jakieś proste przypadki, że in memory nie bierze pod uwagę constraint'ów bazo danowych.
@Mark9wi: A co to ma do tworzenia warstwy abstrakcji repository/UoW nad EF? Testy in memory to fajna idea, ale w bardziej skomplikowanych przypadkach nie działa
@Mark9wi: Na takie przypadki są już testy integracyjne, bez mockowania persystencji. Naciąłem się już na providera In memory i dlatego go nie używam (główny "ficzer" w postaci przenoszenia stanu między odizolowanymi testami skutecznie mnie do niego zniechęcił), ale SQLite dawał radę.
#csharp #programowanie
1. W przypadku CRUDów ma to sens, w przypadku większych agregatów raczej nie.
2. W przypadku CQRSa moje komendy i query są zwykle na tyle skomplikowane, że zmiana ORMa spowoduje również zmiany w zapytaniach.
3. W całej karierze nie zmieniłem ORMa, bo tak.
Zdarzały się zmiany bazy np. na nierelacyjną z relacyjnej i vice-versa (Ale co za tym idzie zmieniła się również struktura danych i trzeba było przepisać zapytania itd)