.NET Core Console App + EntityFramework - brak możliwości stworzenia pliku .edmx z modelem wybranych tabel

0

Witam.
Próbuje dojść do tego dlaczego nie mogę sobie wybrać okienkiem jakie tabele chce oraz stworzyć kontekst w aplikacji do bazy danych przy użyciu EntityFrameworkCore.
Czy teraz taki model tworzy się ręcznie? Musze klepać wszystkie te klasy i podpinać odpowiednio pod DbContext?

Where is the EDMX
Ten wpis ma już dwa lata, serio jeszcze tego nie zrobili?

0

Tylko code first jest wspierane przez ef core innego nigdy nie będzie.

0

Czyli jeśli chce zrobić oprogramowanie pod istniejącą bazę to muszę klepać te wszystkie klasy i kolumny ręcznie?

Jest jeszcze opcja użyć .NET Framework, zrobić .edmx i skopiować do projektu .NET Core, dostosować i gotowe. Wiadomo dlaczego MS zrezygnował z tego?

0

Rewelacja! Dzięki @lukaszek016

0
AdamWox napisał(a):

Wiadomo dlaczego MS zrezygnował z tego?

Podejrzewam, że nie chcą wspierać słabego rozwiązania, które na dodatek jest wbrew dobrym praktykom.

0

@somekind: Nie uważasz, że jeśli coś jest wbrew dobrym praktykom to trzeba to poprawić, a nie usunąć? Dlaczego do tej komendy nie są w stanie zrobić interfejsu?

Scaffold-DbContext "Server=(localdb)\mssqllocaldb;Database=Blogging;Trusted_Connection=True;" Microsoft.EntityFrameworkCore.SqlServer -OutputDir Models

Wydaje mi się, że rozwiązaniem jest interfejs do dobrych praktyk. Źle myślę?

0

No więc utrudniają używanie złych praktyk (czyli generowania aplikacji na podstawie bazy), a wspierają używanie dobrych (czyli pisanie najpierw kodu, a potem tworzenie bazy).

0

Czyli automatycznie złą praktyką jest pisanie aplikacji pod gotową bazę czy już za daleko zabrnąłem?

3

wg mnie jedyna sytuacja kiedy "dobrą praktyką" jest robienie aplikacji pod gotową bazę to ratowanie tonącego i migrowanie do nowej aplikacji bez odcinania od razu istniejącej bazy z danymi. Ale z doświadczenia widzę, że wtedy jest prawie pewne, że i tak Twoje obiekty w żaden sposób nie mapują się 1:1 do tabel więc łatwiej użyć np. Dappera zanim się usunie raka w postaci 25 letniej schemy bazy.
Jak w nowej aplikacji zaczynasz od utworzenia bazy to tak, jest to zła praktyka. Wtedy betonujesz się tabelami, bo zamiast dostosowywać kod do wymagań w trakcie developmentu to naginasz go do bazy, byle tylko za często nie robić ALTER/CREATE TABLE. Niestety dużo tutoriali nie przekazuje tego zbyt dosadnie.

Dlatego właśnie MS usunął Database First z EF Core - żeby nie kusiło.

0

Bardziej czepiam się, że czasem piszę się aplikacje pod bazy danych, które nie są naszym autorstwem, a firm trzecich. Wychodzi na to, że bardzo mało jest takich przypadków, stąd MS zdecydował się na usunięcie Database First. Choć i tak cieszę się, że MS zostawił małą furtkę w postaci Scaffold-DbContext, dzięki którego zaoszczędziłem sporo godzin pracy.

0

Bo skoro baza już istnieje i nie masz na nią wpływu, a chcesz dopisać jakąś małą aplikację, które coś tam w tej bazie dłubie, to nie powinieneś używać EF (ani innego ORMa) tylko mikroORMa np. Dappera.

0

A to tego akurat nie wiedziałem. Wydawało mi się, że ORM to ORM i tutaj specyfika systemu nie ma żadnego znaczenia

0

Ponad rok temu pracowałem dla jednego gościa, który mi przysłał projekt, i to było tak skonfigurowane, że musiałem tabele rypać w SQLe, (w tej solucji była aplikacja, która robiła migracje na podstawie plików .sql)
A encje pisałem sam, nie generowałem ich automatycznie. Jak się zapytałem czemu tak, to mi powiedział, że code first to studenckie podejście :).Rrobiłem .Net core 1.1, EF Core i Postgres.

0
AdamWox napisał(a):

A to tego akurat nie wiedziałem. Wydawało mi się, że ORM to ORM i tutaj specyfika systemu nie ma żadnego znaczenia

ORM ma sens wtedy, gdy tworzysz coś od nowa zaczynając od obiektów, a potem chcesz na ich podstawie wygenerować bazę.
Jaki zysk z użycia ORMa do już istniejącej bazy?

0

Sam fakt obsługi danych oparty na obiektach, a nie na zapytaniach z SqlConnection i SqlCommand. Nie upieram się, że Dapper nie ma sensu. Zwyczajnie wydaje mi się, że wybór ORMa nie jest zależne od tego czy bazę już mamy, czy dopiero ją tworzymy.

0

@somekind: np taki sens
Mam app win desktop .Net. Chce zrobić API do tego w net Core.

Scaffold jakoś działa, ale w metodach mapujących tabele dodaje zawsze schemat bazy. Jak baza testowa nazywa się inaczej niż u klienta to trzeba, chyba, zawsze usuwać.
Albo czegoś nie wiem.

0
AdamWox napisał(a):

Sam fakt obsługi danych oparty na obiektach, a nie na zapytaniach z SqlConnection i SqlCommand. Nie upieram się, że Dapper nie ma sensu. Zwyczajnie wydaje mi się, że wybór ORMa nie jest zależne od tego czy bazę już mamy, czy dopiero ją tworzymy.

Ideą Dappera jest korzystanie z obiektów.
Jak dla mnie główną przewagą ORMa jest właśnie to, że potrafi stworzyć bazę z kodu. Jeśli nie ma takiej potrzeby, bo baza już jest, to po co zaprzęgać pełen ORM?

jacek.placek napisał(a):

@somekind: np taki sens
Mam app win desktop .Net. Chce zrobić API do tego w net Core.

Scaffold jakoś działa, ale w metodach mapujących tabele dodaje zawsze schemat bazy. Jak baza testowa nazywa się inaczej niż u klienta to trzeba, chyba, zawsze usuwać.
Albo czegoś nie wiem.

No, ale co broni Ci użyć Dappera albo jakiegoś innego mikroframeworka? Jakiego zysku oczekujesz od użycia EF?

0
somekind napisał(a):
AdamWox napisał(a):

Wiadomo dlaczego MS zrezygnował z tego?

Podejrzewam, że nie chcą wspierać słabego rozwiązania, które na dodatek jest wbrew dobrym praktykom.

Zabawne, bo pierwotnie Entity Framework był skoncentrowany na podejściu database first.

Dla człowieka, który wbija śruby młotkiem ORM, który robi coś inaczej zawsze jest złą praktykom.

0

No, ale co broni Ci użyć Dappera albo jakiegoś innego mikroframeworka? Jakiego zysku oczekujesz od użycia EF?

  1. Automatyczny insert kluczy obcych.
  2. Ładowanie powiązanych danych

Do tej pory nikt mi nie odpowiedział jak to zrobić w Dapper.
Dapper - pomoc w zapytaniu z multi mappowaniem

Ideą Dappera jest korzystanie z obiektów.
Jak dla mnie główną przewagą ORMa jest właśnie to, że potrafi stworzyć bazę z kodu. Jeśli nie ma takiej potrzeby, bo baza już jest, to po co zaprzęgać pełen ORM?

Nie twierdze, że któryś z nich jest lepszy. Zwyczajnie EF na start oferuje nieco więcej co zmniejsza mój czas pracy. Różnica czy mam bazę czy nie, kompletnie nie wpływa na decyzję z czego powinienem korzystać, a już tym bardziej nie powinieneś tego określać jako zła praktyka.

0

@somekind: No nic mi nie broni używać Dappera tak jak używać EF.
Nie znam się na Core i nie wiem czy na Linuxie wszystkie zewnetrzne biblioteki dzialają.
Miałem taką sytuację niedawno. Starsza aplikacja winforms z bazą na Mysql. Yrzeba było dodawać proste API. Nie chciałem linkowac klas z winforms więc zescafoldowalem bazą w EF. 2 dni i i jest, z zerowym doświadczeniem Z Core.

0
Gworys napisał(a):

Zabawne, bo pierwotnie Entity Framework był skoncentrowany na podejściu database first.

Najwyraźniej dojrzali do XXI wieku.

AdamWox napisał(a):

Do tej pory nikt mi nie odpowiedział jak to zrobić w Dapper.

Już się poprawiłem.

Nie twierdze, że któryś z nich jest lepszy. Zwyczajnie EF na start oferuje nieco więcej co zmniejsza mój czas pracy. Różnica czy mam bazę czy nie, kompletnie nie wpływa na decyzję z czego powinienem korzystać, a już tym bardziej nie powinieneś tego określać jako zła praktyka.

Ja za złą praktykę uważam rozpoczynanie tworzenia nowego systemu od tabel w bazie danych. Jeśli mamy starą bazę, do której coś dorabiamy, to jest to zupełnie inny problem. I nie mówię, że użycie EF to zła praktyka w tej sytuacji, ale raczej może to być strzelanie z armaty do muchy.
(Tzn. ja w ogóle uważam EF za straszne badziewie i samo myślenie o nim za złą praktykę, ale zostawmy to na boku teraz. ;))

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