[z.....g]

#csharp #heheszki #humorinformatykow #entityframework

[h.....u]

@zmudeg: kuwa, gołe ADO.NET jest tak zyebane, że aż smutek :D ale za to wydajne

[spetz]

@zmudeg: niestety ale EF Core jest słabe, dużo lepiej używać np. Dappera.

[w_o_w]

@hauhauu: @spetz: uuuuuu antyentityframeworkizm.

Możecie podać przykłady w czym EF Core czy EF6 odstaje od Dappera lub ADO.NET?
A jeżeli chodzi o wydajność to są jakieś rzetelne porównania?

Mi w EF Core brakuje "Inheritance: Table per concrete class (TPC)" ale po za tym to wszystkie inne braki dało się w prosty sposób obejść.

[spetz]

@w_o_w: brak lazy loading, group by na poziomie bazy (jest w pamięci) oraz innych - mają się pojawić w niedalekiej przyszłości.

[h.....u]

antyentityframeworkizm

@w_o_w: przecież ja na gołę ADO narzekam. EF to też jest ADO.NET tylko przykryte ( ͡° ͜ʖ ͡°)

A trzymanie logiki w procedurach składowanych powinno być zapomniane.

[w_o_w]

@hauhauu:
Większość problemów z wydajnością w przypadku EF kończy się w tedy gdy wyłączysz Tracking changes co dla zwykłych selectów zawsze było bezsensowne.

Ja też nie cierpię SP ale są zadania, które dla bezpieczeństwa lepiej robić przez SP. I nie tylko bezpieczeństwa ale też i wygody.

@spetz: Racja. Jeszcze tylko kilka miesięcy do 2.1. Faktycznie group by w pamięci dla ogromnych zapytań jest słaby ale po za tym Dapper oferuje

[spetz]

@w_o_w dapper to micro orm, mega wydajny, napisany przez ludzi ze Stacka, podobnie jak ich biblioteka do Redisa i inne, ciekawe narzędzia. Zależy co kto lubi :).

[M.....n]

@spetz: Moim zdaniem EF dobrze nadaje się do 80% przypadków, ale polega przy pozostałych 20% stąd ogólnie jestem zwolennikiem używania EF, a tam gdzie on sobie nie radzi to można skorzystać z procedurki, robiłem też czasami rozwiązanie hybrydowe - czyli używam EF do wygenerowania podstawowej SQLki do stringa a potem dopisuje do niego to co potrzebuje i wysyłam zapytanie ( ͡° ͜ʖ ͡°)