JÀmförelse och val av datamigreringssystem
Datamodellen i utvecklingsprocessen har egenskapen att förÀndras, och vid en viss tidpunkt slutar den att motsvara databasen. Naturligtvis kan databasen tas bort, och dÄ kommer ORM att skapa en ny version som stÀmmer överens med modellen, men en sÄdan procedur skulle leda till förlust av befintliga data. DÀrför handlar migrationssystemets funktion om att, nÀr schemat Àndras, synkronisera det med datamodellen i applikationen utan att förlora befintliga data.
I denna artikel vill vi diskutera olika verktyg för att hantera databas-migrationer. Vi hoppas att denna översikt kommer att vara anvÀndbar för utvecklare som stÄr inför ett sÄdant val.
Uppgift
I vĂ„rt företag pĂ„gĂ„r just nu en aktiv utveckling av nĂ€sta generations produkt â Docs Security Suite (DSS). Serverdelen skrivs i .Net Core, och som databas anvĂ€nds dĂ€rmed Entity Framework Core. NĂ€r vi designar applikationen tillĂ€mpar vi ett Code First- tillvĂ€gagĂ„ngssĂ€tt.
DomĂ€nmodellen för applikationen skapas av flera utvecklare samtidigt â varje utvecklare ansvarar för sin logiska del av systemet.
I föregÄende generation av DSS anvÀndes klassiska Entity Framework Migrations (EF 6) som migrationshanteringssystem. Det har dock uppstÄtt vissa klagomÄl pÄ det, den frÀmsta Àr att EF saknar en rimlig metod för att hantera versionkonflikter. Denna punkt oroar oss fortfarande under buggfixering inom supporten, dÀrav beslutet att övervÀga alternativa alternativ.
Som resultat av diskussionen har följande krav formulerats för migrationshanteringssystemet:
- Stöd för olika databashanterare. Obligatoriskt MS SQL Server, PostgreSQL, Oracle, men potentiellt kan Àven andra anvÀndas.
- Arbeta med ORM. Initialt var det tÀnkt att anvÀnda EF Core, men under designfasen var vi öppna för att övervÀga andra ORM.
- Autogenerering av migrationer. Med tanke pÄ Code First-utveckling önskar vi undvika att "skriva manuellt" migrationer.
- Versionskonflikter. Under distribuerad utveckling kan EF Core krascha pÄ grund av konflikter vid sammanslagning. Detta blir ett betydande problem, eftersom olika delar av applikationen skapas av olika utvecklare, vilket gör att mycket tid gÄr förlorad pÄ varje.
- Utvecklad dokumentation och support. HÀr tror vi att förklaringar inte behövs.
- Kostnadsfrihet. Kriteriet Àr villkorligt, eftersom vi ocksÄ var beredda att övervÀga antingen inte sÄ dyra system eller dyra men perfekta i anvÀndarvÀnlighet.
Som ett resultat av en liten undersökning har följande alternativ identifierats och erkÀnns som önskvÀrda för övervÀgande:
- EF Core Migrationer
- DBup
- RoundhousE
- ThinkingHome.Migrator
- Fluent Migrator
Och nu lite mer i detalj
Naturligtvis var detta det första och frÀmsta valet. Inbyggt verktyg som fungerar ur lÄdan utan nÄgra konstiga knep. En stor mÀngd dokumentation, bÄde officiell och inofficiell, enkelhet osv. Men de klagomÄl som riktades mot klassisk EF Àr fullt aktuella Àven för EF Core.
DÀrför finns följande fördelar med EF Core:
- Microsoft stöd, dokumentation, Àven pÄ svenska, ett enormt community.
- Automatgenerering av migrationer baserat pÄ CodeFirst.
- Till skillnad frÄn EF 6 lagras det inte lÀngre en databasavbild i EF Core. NÀr man arbetar med EF Core Àr det nu inte nödvÀndigt att implementera databasen i Code First.
- Eftersom vi utgÄr frÄn Code First finns möjligheten att hantera en migration för alla nödvÀndiga datatillgÄngsleverantörer.
- NÀr det gÀller leverantörer stöds sÄvÀl PostgreSQL och Oracle som MS SQL Server ;)
Och hÀr Àr nackdelarna:
- Konfliktlösningen ÄterstÄr pÄ samma nivÄ. Det Àr nödvÀndigt att bygga en sekvens av migrationer och uppdatera databasavbilder.
- Beroende av modellerna pÄ vilka migrationerna Àr baserade.
DbUp
DbUp Àr ett .NET-bibliotek som installeras via NuGet och hjÀlper till att tillÀmpa Àndringar pÄ SQL Server. Det spÄrar vilka Àndringsskript som redan har körts och kör de som behövs för att uppdatera databasen. Biblioteket vÀxte fram ur ett open source-bloggmotorprojekt pÄ ASP.NET och finns under MIT-licensen, och koden ligger pÄ GitHub. Migrationer beskrivs med hjÀlp av T-SQL.
Vilka Àr fördelarna hÀr:
- Stöd för ett stort antal databashanteringssystem (MS SQL Server, PostgreSQL, MySQL).
- Eftersom skripten skrivs pÄ T-SQL Àr de ganska tydliga.
- Konflikter löses ocksÄ med SQL.
Och nackdelarna:
- Trots det stora utbudet av stödda databashanteringssystem ingÄr inte Oracle.
- Det fungerar inte med ORM.
- Att skriva skript i T-SQL "för hand" Àr inte vad vi strÀvar efter.
- Dokumentationen och communityn Àr sÄ dÀr, Àven om de kanske inte behövs nÀr man skriver SQL-skript.
RoundhousE
Detta migrationshanteringsverktyg, som distribueras under Apache 2.0-licensen, fungerar, precis som den föregÄende, med T-SQL migrationsmotorn. Utvecklarna tycks ha prioriterat lösningar pÄ tekniska problem som rör DB-stöd framför att skapa en smidig utvecklingsprocess.
Fördelar:
- Stöder nödvÀndiga databaser (inklusive Oracle)
Nackdelar:
- Oracle (och den för oss irrelevanta Access) stöds inte pÄ .NET Core, endast pÄ .NET Full Framework.
- Fungerar inte med ORM
- Det finns Ànnu mindre dokumentation Àn för det föregÄende verktyget.
- Ă terigen - migrationer skrivs i skript.
ThinkingHome.Migrator
Verktyg för versionsmigration av databasens schema för .NET Core-plattformen, distribueras under MIT-licensen. .
Fördelar:
- Fokuserat pÄ .NET Core
- En förgrenad sekvens av migrationer har implementerats.
- Migrationer loggas.
Nackdelar:
- Senaste uppdateringen var för ett Är sedan. Projektet verkar inte stödjas.
- Stöder inte Oracle (artikeln nÀmner att detta beror pÄ bristen pÄ en stabil implementation av .NET Core - men det var för ett Är sedan).
- Autogenerering av migrationer saknas.
I stort sett verkar projektet lovande, sÀrskilt om det skulle utvecklas, men vi behövde fatta beslut hÀr och nu.
Fluent Migrator
Det mest populĂ€ra migrationsverktyget med en stor armĂ© av anhĂ€ngare. Distribueras under Apache 2.0-licensen. Enligt beskrivningen Ă€r det en migrationsplattform för .NET, liknande Ruby on Rails Migrations. Ăndringar i databasens schema beskrivs i klasser pĂ„ C#.
Det finns fördelar hÀr:
- Stöd för nödvÀndiga databaser
- Stöd för .NET Core
- Ett stort och vÀletablerat community
- Konflikter i migrationer löses sekventiellt - i migrationerna anges en utförandeordning. Dessutom, om det uppstÄr en konflikt kring en entitet, hanteras lösningen vid sammanslagning av koden pÄ samma sÀtt som i övrig kod.
- Det finns profiler som körs efter att migrationen har genomförts framgÄngsrikt och kan innehÄlla servicefunktioner. Senaste uppdateringen var för en mÄnad sedan, vilket innebÀr att projektet Àr aktivt.
Vad gÀller nackdelar finns det:
- Autogenerering av migrationer saknas.
- Saknar koppling till EF-modeller
- Inga databasbilder
Vad blev vÄrt val?
De het mest intensiva diskussionerna har handlat om tvĂ„ parametrar â automatisk migration och hantering av konflikter. Ăvriga faktorer oroade betydligt mindre. Efter diskussionen beslutade teamet att anvĂ€nda Fluent Migrator i det nya projektet. Att hantera konflikter kommer att ge mĂ„nga fler fördelar pĂ„ lĂ„ng sikt.
Slutsatser
SjÀlvklart finns det inga perfekta verktyg. Vi tvingades ocksÄ prioritera vÄra önskemÄl. Men för andra team och andra uppgifter kan andra faktorer vara avgörande. Vi hoppas att denna artikel hjÀlper dig att göra ditt val.
KĂ€lla: habr.com
