czekaj bo czegoś nie łapie, oczekiwałeś że ORM będzie Ci sam z siebie walił jakieś JOINy do innych tabel?
No tak na moje oko to nie łapiesz dwóch rzeczy: SQL (bo żadne joiny nie są potrzebne, wystarczy select z where) i tego, do czego służy ORM.
Tak, oczekuję, że ORM będzie ładował obiekty wtedy, gdy są potrzebne do wykonania danej operacji. Jeśli nie potrzebujemy takiego zachowania, to prawdopodobnie nie potrzebujemy też ORMa.
Fajnie że ten wyszedł, bo to tylko kolejny argument ku temu, aby częściej w dyskusjach pokazywać kod, bo kod najlepiej weryfikuje rzeczywistość :)
Jaki znowu kwiatek?! Lazy loading to podstawowy mechanizm i idea stojąca za ORM.
Mógłbyś podać przykład?
Customer
ma Address
, Address
ma Country
, a kolekcja Country
sobie siedzi skeszowana w słowniku w pamięci.
Użycie builder.OwnsMany
w klasie konfiguracyjnej to naginanie się do ograniczeń ORMa?
Tak, skoro ORM nie działa jak ORM, to jest mocno ograniczony.
Zobacz sobie jaki SQL wypluwa EF Core po użyciu OwnsMany
, a potem pokaż @WeiXiao, żeby zobaczył jak wyglądają joiny robione pod spodem, żeby następnym razem nie wpadał na dziwne insynuacje pod adresem NH.
Shadow properties
byly już w 2017: https://stackoverflow.com/a/47650462/13172711
W sumie to chyba od wersji 1.1 z 2016? https://csharp.christiannagel.com/2016/11/07/efcorefields/
Myślę, że już w 2016
to najbardziej udany dowcip w tym wątku. ;)
Nie róbmy proszę wojny pomiedzy EF i NH bo nie o tym był temat :)
Nie wiem czy to do mnie uwaga, ale ja z EF tylko lekko kpię, NH to kto inny tu przywołał.
Może mi ktoś dać odpowiedz czy pobieranie danych z bazy moze opierać się na serwisie któy ma metody typu:
public async Task<User> GetByName(string name)
{
return await context.Users.FirstOrDefaultAsync(u=>u.Name==name);
}
czy jednak tak jest zle i powinno się robić inaczej (jak?)
@kalimata: A co Ci da to, że zmienisz nazwę takiej klasy z DAO czy tam repozytorium na serwis? Absolutnie nic, a nawet mniej niż nic, bo serwis to to nie będzie.
Zastanów się nad dwiema rzeczami:
- Czy w ogóle potrzebujesz takiej klasy. Każdy wrapper ma jedną zasadniczą wadę - ogranicza możliwości tego, co opakowuje. Czasami to jest potrzebne, ale użyte w złym miejscu powoduje tylko problemy. Alternatywa jest prosta - w kodzie, który implementuje Twój przypadek użycia, używaj ORMa bezpośrednio. Bez dodatkowej warstwy, za to z pełnią możliwości.
- A jeśli uważasz, że potrzebujesz takiego wrappera, to niech on coś wnosi. Robienie wrappera na ORMa z metodą, która przyjmuje jakieś
Func<cośtam>
to jest absurd, przecież to już potrafi ORM. Wrapper niech dostarcza jakiejś abstrakcji i pozwoli jego użytkownikowi nie wiedzieć jak coś ma być zrobione, tylko co ma być zrobione. Dlatego zdecydowanie więcej sensu ma tworzenie metod, tak jak to zaproponowałeś: GetByCośtam
.