Entity Framework tylko do migracji

Odpowiedz Nowy wątek
2019-02-01 11:58
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
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
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
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.


Java to taki C# tyle że z gorszą składnią.
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
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
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
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
Liczba odpowiedzi na stronę

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