Entity Framework tylko do migracji

Odpowiedz Nowy wątek
2019-02-01 11:58

Rejestracja: 1 rok temu

Ostatnio: 9 godzin temu

0

Cześć,

Do tej pory we wszystkich projektach wykorzystujących bazę używałem EF. Niestety coraz bardziej tracę zaufanie do niego i chciałbym SQL pisać samemu. Bardzo wygodną sprawą do tej pory były migracje. Jedna komenda i tabelki zaktualizowane. Przy tym chciałbym zostać ale już same zapytania wykonywać przy użyciu np. Dappera. Pytanie teraz czy takie podejście ma sens, żeby pakować dwa ORMy do jednego projektu?


Pozostało 580 znaków

2019-02-01 12:00
Moderator

Rejestracja: 12 lat temu

Ostatnio: 21 godzin temu

Lokalizacja: Wrocław

0

No na pewno większy niż używanie EF do odczytu.
Insert/update też nie chcesz robić przy pomocy EF? Dlaczego?


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."

Pozostało 580 znaków

2019-02-01 12:05

Rejestracja: 1 rok temu

Ostatnio: 9 godzin temu

0

@somekind Insert/update jest jak najbardziej ok. Po prostu mam w swoim projekcie parę raportów do zrobienia i moje przygody z EF pokazały tylko tyle, że nie radzi sobie ze zbyt skomplikowanymi konstrukcjami LINQ (sporo many to many). Na mysli miałem zachowanie pewnej spójności. EF - migracje, Dapper - zapytania.


edytowany 1x, ostatnio: Szekel, 2019-02-01 12:07

Pozostało 580 znaków

2019-02-01 12:10

Rejestracja: 16 lat temu

Ostatnio: 9 godzin temu

Lokalizacja: Kraków

2

W EF też możesz pisać SQL samemu:
Raw SQL Queries
Query Types

Do tej pory właśnie używałem EF do zapisów a Dappera do odczytów, ale mam zamiar porzucić Dapper i wszystko robić za pomocą EF core 2.1 w kolejnym projekcie.


It's easy to hate code you didn't write, without an understanding of the context in which it was written.
edytowany 1x, ostatnio: neves, 2019-02-01 12:11
Są jakieś różnice wydajnościowe przy raw-sql a Dapper? Bo faktycznie może to jest dobra droga. :D - Szekel 2019-02-01 12:17
stary EF sporo odstawał wydajnościowo od czegokolwiek, natomiast nowy EF jest nieznacznie wolniejszy od Dappera - neves 2019-02-01 12:24

Pozostało 580 znaków

2019-02-01 13:21

Rejestracja: 4 lata temu

Ostatnio: 11 godzin temu

Lokalizacja: UK

2

Nie ma za bardzo sensu używać EF tylko do migracji. Możesz do tego użyć dedykowane narzędzia, np. DbUp. Sam piszesz skrypty aktualizujące, a DbUp zapewnia że każdy skrypt zostanie wykonany tylko raz na bazie (chociaż można mieć skrypty wykonywane za każdym razem, ale to inna sprawa).


Na każdy złożony problem istnieje rozwiązanie które jest proste, szybkie i błędne.

Pozostało 580 znaków

2019-02-04 16:36

Rejestracja: 1 rok temu

Ostatnio: 11 miesięcy temu

0

W projekcie, w którym obecnie pracuję mamy database first. EF mapuje bazę danych na aplikację. Używaliśmy sporo linq żeby wyciągać różne dane. Jednak było to wolne i w aplikacji utrzymywanie tych różnych zapytań wprowadzało bałagan. Rozwiązaliśmy to widokami po stronie db. Możesz je tak samo zaciągać jak tabele z bazki.
Generujemy jak wyglądać raport po stronie bazy i tylko zaciągamy go z danego widoku.
Podobnie z ViewModelami. Większość przygotowanych mamy z widoków na bazie danych. Nie musimy ich kleić po stronie aplikacji. Mega wygodne.

Pozostało 580 znaków

2019-02-04 20:57

Rejestracja: 2 lata temu

Ostatnio: 10 godzin temu

0

Tak. Ma to sens.
Szczególnie w takim badziewiu jak EF ( @somekind dawaj kciuka za jazdę po EF :)
Chyba używanie Dappera łączy się zwykle z jakimś ORMem do write/update. Ja mam tylko w jednym projekcie Dappera w api net core i oczywiście razem z EF Core. A jeszcze sama bazą jest generowana migracjami w EF6 :). Zoologia.
Same migracje to bardzo dobry mechanizm.

Ja daję kciuki za pisanie z sensem, a nie za jeżdżenie po niepełnosprawnych frameworkach. - somekind 2019-02-04 20:59

Pozostało 580 znaków

Odpowiedz

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0