Wpis z mikrobloga

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
  • 9
@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.