Jämförelse och urval av datamigreringssystem
Datamodellen tenderar att förändras under utvecklingsprocessen, och någon gång motsvarar den inte längre databasen. Naturligtvis kan databasen raderas, och då kommer ORM att skapa en ny version som matchar modellen, men denna procedur kommer att leda till förlust av befintliga data. Migreringssystemets funktion är alltså att säkerställa att det, som ett resultat av en schemaändring, synkroniseras med datamodellen i applikationen utan att befintlig data går förlorad.
I den här artikeln vill vi titta på olika verktyg för att hantera databasmigreringar. Vi hoppas att denna recension kommer att vara användbar för utvecklare som står inför ett liknande val.
Uppgift
Vårt företag utvecklar för närvarande aktivt nästa generations produkt – Docs Security Suite (DSS). Serverdelen är skriven i .Net Core och Entity Framework Core används som DBMS. När vi designar en applikation använder vi Code First-metoden.
Applikationsdomänmodellen skapas av flera utvecklare samtidigt - var och en ansvarar för sin egen logiska del av systemet.
Den tidigare generationen av DSS använde den klassiska Entity Framework Migrations (EF 6) som migrationshanteringssystem. Det har dock samlats några klagomål mot det, det främsta är att EF saknar ett vettigt tillvägagångssätt för att lösa versionskonflikter. Detta faktum gör oss fortfarande upprörda när vi fixar buggar som en del av supporten, så vi bestämde oss för att överväga alternativa alternativ.
Som ett resultat av diskussionen bildades följande krav för migrationshanteringssystemet:
- Stöd för olika DBMS. MS SQL Server, PostgreSQL, Oracle krävs, men det är potentiellt möjligt att använda andra
- Jobbar med ORM. Från början var det planerat att använda EF Core, men vid designstadiet var vi redo att överväga andra ORM:er
- Automatisk generering av migrationer. Med hänsyn till utvecklingen av Code First vill jag undvika behovet av att "handskriva" migrationer
- Versionskonflikter. I en distribuerad utvecklingsmiljö, vid sammanslagning, kan EF Core drabbas av konflikter. Detta blir ett betydande problem eftersom olika delar av applikationen skapas av olika utvecklare, så du måste spendera mycket tid på varje
- Avancerad dokumentation och support. Här, förefaller det oss, behövs ingen förklaring
- Fri. Kriteriet är villkorat, eftersom system inte är särskilt dyra eller dyra, men idealiska i bekvämlighet, var vi också redo att överväga
Som ett resultat av lite forskning hittades följande alternativ och ansågs önskvärda att överväga:
- EF Core Migrations
- DBup
- RoundhouseE
- ThinkingHome.Migrator
- Flytande migrator
Och nu lite mer detaljer
Naturligtvis var detta det första och viktigaste alternativet att välja. Ett inhemskt instrument som fungerar ur lådan utan att pilla runt med en tamburin. En stor mängd dokumentation, officiell och inte så, enkelhet, etc. Men klagomålen om klassisk EF är också ganska relevanta för EF Core.
Således framhävs fördelarna med EF Core:
- Microsoft support, dokumentation, inklusive på ryska, enorma gemenskap
- Automatisk generering av migrationer baserade på CodeFirst
- Jämfört med EF 6 lagrar EF Core inte längre en ögonblicksbild av databasen. När du arbetar med EF Core i Code First är det inte längre nödvändigt att distribuera en databas
- Eftersom vi dansar från Code First är det möjligt att genomföra en migrering till alla nödvändiga dataåtkomstleverantörer
- När det gäller leverantörer, PostgreSQL stöds, Oracle stöds, etc., etc., och även MS SQL Server
Och även nackdelarna:
- Konfliktlösningen låg kvar på samma nivå. Det är nödvändigt att sekvensera migrationer och uppdatera ögonblicksbilder av databasen
- Beroende av modellerna som migreringarna genereras på
DbUp
DbUp är ett .NET-bibliotek som installeras av NuGet och hjälper till att driva ändringar i SQL Server. Den håller reda på vilka ändringsskript som redan har körts och kör de som är nödvändiga för att uppdatera databasen. Biblioteket växte fram ur ett projekt för en bloggmotor med öppen källkod på ASP.NET och finns under en MIT-licens, och koden finns på GitHub. Migreringarna beskrivs med T-SQL.
Vad är fördelarna:
- Stöd för ett stort antal DBMS (MS SQL Server, PstgreSQL, MySQL)
- Eftersom skripten är skrivna i T-SQL ser de ganska enkla ut
- Konflikter löses också med SQL
Och nackdelarna:
- Med alla de olika DBMS som stöds är Oracle inte en av dem
- Interagerar inte med ORM
- Att skriva T-SQL-skript för hand är inte vad vi siktade på
- Dokumentationen och communityn är så som så, även om de kanske inte är nödvändiga när det gäller att skriva SQL-skript.
RoundhouseE
Detta migrationshanteringsverktyg, distribuerat under Apache 2.0-licensen, liksom den tidigare, körs på T-SQL-migreringsmotorn. Tydligen prioriterade utvecklarna att lösa tekniska problem angående DBMS-stöd, snarare än att skapa en bekväm utvecklingsprocess.
Fördelar:
- Stöder nödvändig DBMS (inklusive Oracle)
Nackdelar:
- Oracle (liksom Access, vilket är irrelevant för oss) stöds inte på .NET Core, bara på .NET Full Framework
- Fungerar inte med ORM
- Det finns ännu mindre dokumentation än det tidigare verktyget
- Återigen – migrationer skrivs av skript
ThinkingHome.Migrator
Ett verktyg för migrering av versioner av databasschema till .NET Core-plattformen, distribuerat under MIT-licensen. .
Fördelar:
- Designad för .NET Core
- Implementerade en förgrenande sekvens av migrationer
- Implementerade migrationsloggning
Nackdelar:
- Senast uppdaterad för ett år sedan. Projektet stöds tydligen inte
- Stöds inte av Oracle (artikeln säger att detta beror på bristen på en stabil implementering för .NET Core - men det här är ett år sedan)
- Ingen automatisk generering av migrationer
Sammantaget ser projektet lovande ut, särskilt om det skulle utvecklas, men vi behövde ta ett beslut här och nu.
Flytande migrator
Det mest populära migreringsverktyget med en stor armé av fans. Distribueras under Apache 2.0-licensen. Som anges i beskrivningen är det ett migreringsramverk för .NET, liknande Ruby on Rails Migrations. Ändringar av databasschemat beskrivs i C#-klasser.
Det finns fördelar här:
- Stöd för erforderligt DBMS
- .NET Core-stöd
- Stort utvecklat samhälle
- Konflikter mellan migreringarna löses sekventiellt – ordningsföljden för utförande av migreringarna anges. Dessutom, om en konflikt uppstår kring en enhet, när koden slås samman, löses den på samma sätt som i resten av koden
- Det finns profiler som körs efter en lyckad migrering. Och de kan bära servicefunktioner. Den senaste uppdateringen var för en månad sedan, det vill säga projektet lever
När det gäller nackdelarna, här är de:
- Ingen automatisk generering av migrationer
- Ingen koppling till EF-modeller
- Inga ögonblicksbilder av databasen
Vad var vårt val?
De hetsiga debatterna kretsade kring två parametrar - automatisk generering av migrationer och förnuftig lösning av konflikter. Andra faktorer var mycket mindre skrämmande. Som ett resultat, baserat på resultaten av diskussionen, beslutade teamet att använda Fluent Migrator i det nya projektet. För att lösa konflikter i framtiden kommer att ge mycket fler fördelar.
Resultat
Naturligtvis finns det inga perfekta verktyg. Så vi var tvungna att prioritera våra "önskningar" för att göra ett val. För andra team och andra uppgifter kan dock andra faktorer vara avgörande. Vi hoppas att den här artikeln hjälper dig att göra ett val.
Källa: will.com