Tworzenie bazy danych .NET - jak preferujecie?

Tworzenie bazy danych .NET - jak preferujecie?
hercules
  • Rejestracja: dni
  • Ostatnio: dni
  • Postów: 77
0

Chodzi mi o to czy wolicie tworzyć projekt bazodanowy i w nim utrzymywać kod czy raczej Code First i bawić się w migracje?
Jakie wg Was jest lepsze podejście przy tworzeniu dużych systemów?

Pixello
  • Rejestracja: dni
  • Ostatnio: dni
  • Lokalizacja: Podkarpacie
  • Postów: 448
2

Code first - właśnie zmusiłem mój zespół do nauczeniua sie tego i teraz mi dziekuja - tylko jedno ale, trzeba od razu pomyslec o separacji i zrobic poprawnie, tj osobny projekt do migracji bo predzej czy pozniej projekt sie rozrosnie i potem jest ból przy zmianie tego.

mariano901229
  • Rejestracja: dni
  • Ostatnio: dni
  • Postów: 597
0

Jak poprzednik tylko CodeFirst w przypadku EF. Chyba, że mamy sytuacje kiedy baza danych już istnieje, no to wtedy wyboru raczej nie mamy i Database First. Ktoś kiedyś użył tego trzeciego podejścia da EF - Model First ? Istnieje to w ogóle teraz w EF dla .NET Core ?

Pixello
  • Rejestracja: dni
  • Ostatnio: dni
  • Lokalizacja: Podkarpacie
  • Postów: 448
0

Jest scaffolding bazy do model first w ef core, mozna tez zamrozic istniejacy schemat i zmieniac on top of it swoje rzeczy, ale wole juz scaffolding i poprawic to co automat wygenerowal zle - wtedy przynajmniej mozna robic zmiany istniejacych rzeczy

Ogolnie opowi polecam
https://docs.microsoft.com/en-us/ef/core/managing-schemas/migrations/?tabs=dotnet-core-cli

JP
  • Rejestracja: dni
  • Ostatnio: dni
  • Postów: 1065
0
mariano901229 napisał(a):

Jak poprzednik tylko CodeFirst w przypadku EF. Chyba, że mamy sytuacje kiedy baza danych już istnieje, no to wtedy wyboru raczej nie mamy i Database First. Ktoś kiedyś użył tego trzeciego podejścia da EF - Model First ? Istnieje to w ogóle teraz w EF dla .NET Core ?

Mamy wybór. Możemy napisać mapowanie, które obsłuży istniejącą bazę. I to isę wiąże z tym co @Pixello napisał.
Jeśli masz osobny projekt do migracji to obok masz drugi kod, który mapuje to co jest w projekcie migracji na potrzeby programu i możesz sobie łatwiej podzielić dbcontexty na kawałki. Kiedyś to sprawdzałem w jednym z projektów i nieźle działa. Dodatkowo jest odporność na zmianę schematu db w jakimś zakresie bo jak migracja coś zmieni to wcześniejsze wersje programu mogą działać normalnie bo mają własne mapowanie dbcontextów.

AK
  • Rejestracja: dni
  • Ostatnio: dni
  • Postów: 44
0

Zdecydowanie Code First przy użyciu EF. Model First ? O tyle co dla Database first potrafiłbym wymienić plusy względem Code first to dla podejścia model first nie potrafię

hercules
  • Rejestracja: dni
  • Ostatnio: dni
  • Postów: 77
0

Dzięki wszystkim za odpowiedzi.

A jak tworzycie i ogarniacie utrzymanie procedur i widoków w Code First?
O tyle o ile z klas tworzenie tabel jest ok, o tyle jak to wygląda z procedurami?

JP
  • Rejestracja: dni
  • Ostatnio: dni
  • Postów: 1065
0

Ja tworzę pusta migracje i pisze SQL w metodzie Sql().

AK
  • Rejestracja: dni
  • Ostatnio: dni
  • Postów: 44
0

U nas staramy się nie pisać procedur, a jeśli już jakieś stare procedury są, to zostają tam, gdzie zostały utworzone i tylko ich używamy. Nowe prawdopodobnie też by tam trafiły, żeby nie robić nagle kilku miejsc gdzie są przetrzymywane

Zarejestruj się i dołącz do największej społeczności programistów w Polsce.

Otrzymaj wsparcie, dziel się wiedzą i rozwijaj swoje umiejętności z najlepszymi.