Vergelyking en seleksie van data-migrasiestelsels
Die datamodel is geneig om te verander tydens die ontwikkelingsproses, en op 'n stadium hou dit op om met die databasis ooreen te stem. Natuurlik kan die databasis uitgevee word, en dan sal die ORM 'n nuwe weergawe skep wat by die model sal pas, maar hierdie prosedure sal lei tot die verlies van bestaande data. Die funksie van die migrasiestelsel is dus om dit te sinchroniseer met die datamodel in die toepassing as gevolg van 'n skemaverandering sonder om bestaande data te verloor.
In hierdie artikel wil ons verskeie instrumente oorweeg om databasismigrasies te bestuur. Ons hoop dat hierdie resensie nuttig sal wees vir ontwikkelaars wat voor 'n soortgelyke keuse te staan kom.
Taak
Ons maatskappy is tans aktief besig om die volgende generasie van die produk te ontwikkel - Docs Security Suite (DSS). Die bedienerdeel is in .Net Core geskryf, en die Entity Framework Core word onderskeidelik as die DBMS gebruik. Wanneer ons 'n toepassing ontwerp, gebruik ons die Code First-benadering.
Die toepassingsdomeinmodel word deur verskeie ontwikkelaars gelyktydig geskep - elkeen is verantwoordelik vir sy eie logiese deel van die stelsel.
Die vorige generasie DSS het die klassieke Entity Framework Migrations (EF 6) as die migrasiebestuurstelsel gebruik. Sommige klagtes het egter teen hom opgehoop, waarvan die belangrikste was dat EF nie 'n gesonde benadering het om weergawekonflikte op te los nie. Hierdie feit ontstel ons steeds wanneer ons foutoplossings maak as deel van ondersteuning, daarom is besluit om alternatiewe opsies te oorweeg.
As gevolg van die bespreking is die volgende vereistes vir die migrasiebestuurstelsel gevorm:
- Ondersteuning vir verskeie DBBS. Verpligte MS SQL Server, PostgreSQL, Oracle, maar dit is moontlik om ander te gebruik
- Werk met ORM Aanvanklik was EF Core veronderstel om gebruik te word, maar in die ontwerpstadium was ander ORM's gereed om oorweeg te word
- Outomatiese generering van migrasies. Gegewe die ontwikkeling van Code First, wil ek die behoefte vermy om migrasies te "verf met penne".
- Weergawe bots. In 'n verspreide ontwikkelingsomgewing, wanneer dit saamsmelt, kan EF Core op konflikte val. Dit word 'n beduidende probleem aangesien verskillende dele van die toepassing deur verskillende ontwikkelaars geskep word, so jy moet baie tyd aan elke
- Ontwikkel dokumentasie en ondersteuning. Hier, lyk dit vir ons, is geen verduideliking nodig nie.
- Vry. Die maatstaf is voorwaardelik, aangesien ons nie baie duur stelsels of duur nie, maar ideaal in gerief was, ook gereed was om te oorweeg
As gevolg van 'n klein studie is die volgende opsies gevind en as wenslik beskou vir oorweging:
- EF Core Migrations
- DBup
- RoundhouseE
- ThinkingHome.Migrator
- Vlot Migrator
En nou nog 'n bietjie
Natuurlik was dit die eerste en belangrikste opsie vir keuse. ’n Inheemse instrument wat uit die boks werk sonder enige tamboeryndans. 'n Groot hoeveelheid dokumentasie, amptelik en nie so nie, eenvoud, ens. Die eise wat teen die klassieke EF gemaak word, is egter ook baie relevant vir EF Core.
Dus word die voordele vir EF Core uitgelig:
- Microsoft ondersteuning, dokumentasie, insluitend in Russies, 'n groot gemeenskap
- Outo-generering van migrasies gebaseer op CodeFirst
- In vergelyking met EF 6, stoor EF Core nie meer 'n momentopname van die databasis nie. Die implementering van die databasis is nie meer nodig wanneer jy met EF Core in Code First werk nie
- Aangesien ons vanaf Code First dans, is dit moontlik om een migrasie na alle vereiste datatoegangsverskaffers uit te voer
- Wat verskaffers betref, dit ondersteun PostgreSQL, Oracle, ens., ens., en selfs MS SQL Server
En ook nadele:
- Konflikoplossing bly dieselfde. Dit is nodig om 'n reeks migrasies te bou en databasisfoto's op te dateer
- Afhanklikheid van modelle gebaseer op wat migrasies gegenereer word
DbUp
DbUp is 'n .NET-biblioteek wat deur NuGet geïnstalleer word en help om veranderinge aan SQL Server te stoot. Dit hou tred met watter veranderingsskrifte reeds uitgevoer is en loop dié wat nodig is om die databasis op te dateer. Die biblioteek het gegroei uit 'n oopbron-blog-enjinprojek op ASP.NET en bestaan onder die MIT-lisensie, en die kode is op GitHub. Migrasies word beskryf met behulp van T-SQL.
Wat is die voordele hier:
- Ondersteuning vir 'n groot aantal DBMS (MS SQL Server, PstgreSQL, MySQL)
- Aangesien die skrifte in T-SQL geskryf is, lyk dit redelik eenvoudig.
- Konflikte word ook met SQL opgelos
En die nadele:
- Met al die verskeidenheid ondersteunde DBBS, is Oracle nie een van hulle nie
- Werk nie met ORM nie
- Om skrifte in T-SQL met "handvatsels" te skryf, is nie waarna ons gestreef het nie
- Dokumentasie en gemeenskap is so-so, alhoewel in terme van die skryf van SQL-skrifte, dit dalk nie nodig is nie.
RoundhouseE
Hierdie migrasiebestuurnutsmiddel, versprei onder die Apache 2.0-lisensie, soos die vorige een, loop op die T-SQL-migrasie-enjin. Blykbaar het die ontwikkelaars daarop gefokus om tegniese probleme op te los in terme van die ondersteuning van die DBBS, eerder as om 'n gemaklike ontwikkelingsproses te skep.
Pros:
- Ondersteun vereiste DBMS (insluitend Oracle)
Nadele:
- Oracle (sowel as Access, wat vir ons irrelevant is) word nie op .NET Core ondersteun nie, slegs op .NET Full Framework
- Werk nie met ORM nie
- Selfs minder dokumentasie as die vorige instrument
- Weereens - migrasies word deur skrifte geskryf
ThinkingHome.Migrator
Gereedskap vir weergawe migrasie van die databasisskema na die .NET Core-platform, versprei onder die MIT-lisensie. .
Pros:
- Gepasmaak vir .NET Core
- 'n Vertakkende reeks migrasies geïmplementeer
- Migrasie-aantekening geïmplementeer
Nadele:
- Die laaste opdatering was 'n jaar gelede. Die projek word blykbaar nie ondersteun nie
- Word nie deur Oracle ondersteun nie (die artikel verklaar dat dit te wyte is aan die gebrek aan 'n stabiele implementering vir .NET Core - maar dit is 'n jaar gelede)
- Outo-generering van migrasies ontbreek
Oor die algemeen lyk die projek belowend, veral as dit ontwikkel het, maar ons moes hier en nou 'n besluit neem.
Vlot Migrator
Die gewildste migrasie-instrument met 'n groot aanhangersbasis. Versprei onder die Apache 2.0-lisensie. Soos in die beskrywing genoem, is 'n migrasieraamwerk vir .NET, soortgelyk aan Ruby on Rails Migrations. Databasisskemaveranderings word in C#-klasse beskryf.
Daar is pluspunte hier:
- Ondersteuning vir die vereiste DBBS
- .NET Core ondersteuning
- Groot ontwikkelde gemeenskap
- Migrasiekonflikte word opeenvolgend opgelos - die migrasievolgorde word gespesifiseer. Daarbenewens, as 'n konflik ontstaan rondom een entiteit, wanneer die kode saamgevoeg word, word dit op dieselfde manier opgelos as in die res van die kode.
- Daar is profiele wat na 'n suksesvolle migrasie loop. En hulle kan diensfunksies dra. Die laaste opdatering was 'n maand gelede, dit wil sê, die projek leef
Wat die nadele betref, dan hier:
- Outo-generering van migrasies ontbreek
- Ontbrekende kommunikasie met EF-modelle
- Geen db-kiekies nie
Wat was ons keuse?
Die warmste debat het om twee parameters gedraai - outomatiese generering van migrasies en gesonde konflikoplossing. Ander faktore het baie minder geskrik. Gevolglik het die span op grond van die resultate van die bespreking besluit om Fluent Migrator in die nuwe projek te gebruik. Vir die oplossing van konflikte in die toekoms sal 'n veel groter aantal pluspunte meebring.
Bevindinge
Natuurlik is daar geen perfekte gereedskap nie. Ons moes dus ons "Wishlist" prioritiseer om 'n keuse te maak. Vir ander spanne en ander take kan ander faktore egter deurslaggewend wees. Ons hoop dat hierdie artikel jou sal help om jou keuse te maak.
Bron: will.com