Czy Entity Framework Code First jest trochę bezsensowny / bezużyteczny w produkcji i jaka jest dobra strategia EF dla produkcji?

Ostatnio programuję z Entity Framework 4.1 Code First i uwielbiam go do programowania, ale mając tylko plan końcowy i szybko zmieniającą się listę funkcji, ciągle modyfikuję klasę / bazę danych, aby spełnić potrzeby aplikacji.

W fazie rozwoju nie ma danych na żywo i mogę z łatwością usunąć całą bazę danych, więc jest ona odtwarzana przy użyciu nowego schematu, ale oczywiście, kiedy jest na żywo - to bardzo źle!

Jedyne rozwiązania, które widzę, to upuszczenie tabeli metadanych i ręczne zsynchronizowanie bazy danych lub po prostu usunięcie i ponowne uruchomienie.

Osobiście wolę pierwszą metodę, ponieważ myślę, że o wiele łatwiej będzie dodać kolumnę / tabelę niż odtworzyć i migrować dane, ale, chyba że coś przeoczyłem, całkowicie odchodzi od Code First.

Tak naprawdę pytanie brzmi: czy Code First dotyczy tylko początkowego rozwoju i jaka jest dobra strategia zarządzania EF dla środowiska produkcyjnego?

frameworks entity-framework

— wilhil
źródło

— Chciałem

Odpowiedzi:

Moim zdaniem automatyczne tworzenie baz danych najpierw służy wyłącznie do programowania. Odpowiedziałem na podobne pytania dotyczące przepełnienia stosu, w którym opisałem zarówno sposób aktualizacji bazy danych, jak i dlaczego automatyczna funkcjonalność jest zła w produkcji:

Aktualizacja bazy danych jest zadaniem półautomatycznym. Nie powinna istnieć automatyczna niesprawdzona magia - ponadto EF 4.1 obecnie nie ma takiej magii (jest tylko prezentacja na temat funkcji, nad którymi pracuje zespół ADO.NET).

Możesz również sprawdzić to pytanie, aby lepiej zrozumieć, w jaki sposób strony internetowe są aktualizowane.

— Ladislav Mrnka
źródło

Witam ponownie! -Jesteś szybki w pytaniach EF! :) ... Nie wiem, gdzie byłbym bez ciebie!

— wilhil

Kilka miesięcy później mój program jest całkiem skończony ... Oznaczam to jako odpowiedź, ale zastanawiałem się, czy coś się zmieniło / czy są jakieś zasoby, które mogą pomóc?

— wilhil

Opublikowano pierwszą publiczną wersję zapoznawczą „Migracji”. blogs.msdn.com/b/adonet/archive/2011/07/27/…

— Ladislav Mrnka

Dzięki, patrząc na to teraz! Uwielbiałem programować w Code First, ale denerwuję się / martwię o zmianę w przyszłości!

— wilhil

Jak radzić sobie z przypadkiem, w którym StoredProcs lub widoki są tworzone bezpośrednio w bazie danych do innych celów, np. Raportowania, które nie są używane przez aplikację. Musielibyśmy najpierw wiedzieć, na które SP wpływa zmiana schematu w kodzie.

— softveda

Obsługuj skrypty aktualizacji .

W samej bazie danych utrzymuj tabelę, w której przechowywany jest rekord z wersją schematu.

Po uruchomieniu aplikacja wykrywa wersję w stosunku do wersji, która ma być używana przez pliki binarne. Jeśli się różni, wykonuje (lub prosi użytkownika) skrypty aktualizacji.

Nie zapomnij najpierw wykonać kopii zapasowej bazy danych.

Następny krok: jesteś zwolniony;) Aktualizacje bazy danych nie powinny ahppen automatycznie bez uprzedniej kopii zapasowej - i być może w czasie przestoju, nie wtedy, gdy JEDEN UŻYTKOWNIK uruchomi nowszą wersję. Twoje podejście jest idealne - do zamykania większych wdrożeń z mnóstwem błędów.

— TomTom

@TomTom: to zależy. Od kilku lat działamy bezbłędnie aplikację DB, która robi dokładnie to: automatyczne zmiany schematu dla nowej wersji, wykonywane przez aplikację, gdy wykryje zbyt starą wersję. Kopie zapasowe są również wykonywane codziennie, a wszystkie zmiany schematu są kompatybilne wstecz (tylko dodając pola i tabele, nigdy nie usuwając żadnych). Zgadzam się, że wspomniane miary są ważne, gdy zmiany nie są kompatybilne wstecz i nie można zagwarantować jednoczesnej aktualizacji wszystkich aplikacji klienckich (na przykład dla dużych firmowych baz danych).

— Doc Brown,

Na górze, jeśli zmiany nie są trywialne. Spróbuj zmienić pole w tabeli 2 TB (i tak, radzę sobie z tym - i nie jest to nawet hurtownia danych). Wystawiłeś się na scenariusz, w którym gromadzisz dług techniczny, ponieważ możesz tylko DODAĆ pola, nigdy nie posprzątać.

— TomTom

Pytanie jest w jakiś sposób błędne, ponieważ tworzy połączenia między modelem programowania a środowiskiem wykonawczym, w którym ich nie ma.

Najpierw kod jest przede wszystkim sterownikiem programistycznym i nie jest tak naprawdę podłączony do systemu wykonawczego.

W środowisku produkcyjnym poprawnie skonfigurujesz ustawienie, które zabrania środowisku wykonawczemu możliwości usuwania / aktualizacji modelu db.

— Casper
źródło