nie mogę wypowiedzieć się na temat drugiej ORM, ale ja Użyłem DevExpress XPO do aplikacji skarbcowych od 2007 roku. Schemat zmienia się trochę w każdym wydaniu, ale w ciągu ostatnich lat nastąpiły również duże zmiany w schemacie. W nieco rozszerzonej wersji domyślnego mechanizmu aktualizacji XPO wygodnie pokrył wszystkie zmiany.
Istnieje dobra podstawowa informacja o aktualizowaniu aplikacji XPO pod numerem here.
DevExpress dostarcza narzędzie DBUpdater, które pomaga w aktualizacji środowiska produkcyjnego. Możesz rozszerzyć to narzędzie, aby zaspokoić dodatkowe wymagania. W mojej aplikacji dodaliśmy kilka opcji rejestrowania, podglądu z wycofywaniem, itp.
Każdy moduł ma wirtualne metody UpdateDatabaseBeforeSchemaUpdate() i UpdateDatabaseAfterSchemaUpdate(). Możesz znacząco kontrolować proces aktualizacji w obrębie tych.
Jak wspomina, niektóre uaktualnienia będą obsługiwane automatycznie przez XPO (na przykład, dodając nową kolumnę), ale niektóre rzeczy potrzebują dodatkowego sterowania, takich jak inicjowanie nową kolumnę o wartości domyślnej dla dotychczasowych rekordów.
Na przykład, załóżmy, że MyNewField została dodana do klasy XPO MyEntity w wersji 2.0 aplikacji. Powiedzmy, że domyślnie powinna mieć wartość 3 dla istniejących rekordów. XPO zajmie się tworzeniem nowej kolumny, ale istniejące rekordy będą mieć wartość NULL. (Jeśli określisz wartość domyślną w klasie XPO, będzie ona dotyczyć wyłącznie nowych rekordów). W celu skorygowania wartości dla istniejących zapisów chcesz dodać coś takiego do pliku jednostka modułu przesłonięte UpdateDatabaseAfterSchemaUpdate(): (. Można również użyć ObjectSpace.GetObjects<MyEntity>() i foreach jeśli wolisz, aby uniknąć bezpośredniego SQL)
public override void UpdateDatabaseAfterUpdateSchema()
{
base.UpdateDatabaseAfterUpdateSchema();
if (CurrentDBVersion < new Version(2, 0, 0, 0))
ObjectSpace.GetSession().ExecuteNonQuery(
"UPDATE [MyEntity] SET [MyNewField] = 3 WHERE [MyNewField] IS NULL");
}
W bardziej ekstremalnym przykładzie dzielenia tabeli na dwie części, możesz użyć tej samej metody, ale zamiast tego zastąpisz UpdateDatabaseBeforeUpdateSchema(), uruchom SQL, aby podzielić tabelę, pozwól XPO wykonać inne aktualizacje schematu i, jeśli to konieczne, zapełnij dowolne domyślne wartości w UpdateDatabaseAfterUpdateSchema().
Przekonasz się, że możesz natrafić na problemy z ograniczeniami, np. Naruszenia klucza obcego, więc możesz znaleźć kilka ogólnych procedur, takich jak DropAllForeignKeyConstraints() jako część UpdateDatabaseBeforeUpdateSchema(). Czasami okazuje się, że XPO już coś zapewnia, czasem nie. Brakujące wiązania i indeksy zostaną zregenerowane w aktualizacji schematu. (W moim doświadczeniu przełączanie klucza podstawowego tabeli danych głównych okazało się najtrudniejszą procedurą aktualizacji, aby uzyskać prawo).
Domyślnie połączenia odbywają się w transakcji SQL, więc jeśli coś zawiedzie, wszystkie powinny zostać wycofane.
Twórcy muszą mieć świadomość, kiedy zmiana modelu domeny może spowodować problem z podstawowym schematem.
Do testowania przechowujemy kilka starych baz danych klientów i przeprowadzamy szereg testów przed i po wykonaniu w ramach procesu budowania, aby upewnić się, że obecni klienci są w stanie odpowiednio zaktualizować wersję, z której dokonują aktualizacji. W produkcji, gdy mamy problem z aktualizacją, dane o problemie są dodawane do tej biblioteki testów, aby zapobiec podobnym problemom w przyszłości.
Mamy do czynienia z dużymi międzynarodowymi firmami i bankami. Klienci są zadowoleni z wyniku. W sytuacjach, w których korporacyjne DBA musi podpisać się na temat zmian, nie wydaje się, że mają do dyspozycji narzędzie wiersza poleceń do wykonania aktualizacji, a nie skrypt.
To, co opisałeś, odnosi się do XAF, a nie do XPO. – Yuyo