हमने EF 6 MSSQL और PostgresSQL के साथ दोस्त कैसे बनाए

एक बार MSSQL DBMS के साथ EF 6 पर एक प्रोजेक्ट था। और PostgreSQL के साथ काम करने की क्षमता को जोड़ने की आवश्यकता थी। हमें यहां समस्याओं की उम्मीद नहीं थी, क्योंकि इस विषय पर बड़ी संख्या में लेख हैं, और मंचों पर आप इसी तरह की समस्याओं की चर्चा पा सकते हैं। हालांकि, वास्तव में, सब कुछ इतना सरल नहीं निकला, और इस लेख में हम इस अनुभव के बारे में बात करेंगे, नए प्रदाता के एकीकरण के दौरान हमने जिन समस्याओं का सामना किया, और उनके समाधान के बारे में हमने चुना।

पृष्ठभूमि

हमारे पास एक बॉक्सिंग उत्पाद है, और इसकी पहले से ही स्थापित संरचना है। प्रारंभ में, इसे एक DBMS - MSSQL के साथ काम करने के लिए कॉन्फ़िगर किया गया था। परियोजना में EF 6 कार्यान्वयन (कोड प्रथम दृष्टिकोण) के साथ डेटा एक्सेस परत है। हम ईएफ 6 माइग्रेशन के माध्यम से पलायन के साथ काम करते हैं। माइग्रेशन मैन्युअल रूप से बनाए जाते हैं। डेटाबेस की प्रारंभिक स्थापना कंसोल एप्लिकेशन से कनेक्शन स्ट्रिंग पर संदर्भ के आरंभीकरण के साथ होती है, एक तर्क के रूप में पारित:

static void Main(string[] args) { if (args.Length == 0) { throw new Exception("No arguments in command line"); } var connectionString = args[0]; Console.WriteLine($"Initializing dbcontext via {connectionString}"); try { using (var context = MyDbContext(connectionString)) { Console.WriteLine("Database created"); } } catch (Exception e) { Console.WriteLine(e.Message); throw; } } 

इसी समय, ईएफ इंफ्रास्ट्रक्चर और डोमेन डोमेन एक अन्य परियोजना में वर्णित हैं, जो कि लाइब्रेरी के रूप में कंसोल एप्लिकेशन से जुड़ा है। बुनियादी ढांचा परियोजना में संदर्भ निर्माता इस तरह दिखता है:

 public class MyDbContext : IdentityDbContext<User, Role, Key, UserLogin, UserRole, UserClaim>, IUnitOfWork { public MyDbContext(string connectionString) : base(connectionString) { Database.SetInitializer(new DbInitializer()); Database.Initialize(true); } } 

पहला लॉन्च

हमने जो पहला काम किया, वह दो पैकेजों को परियोजना के लिए nuget: Npgsql और EntityFramework6.Npgsql के माध्यम से जोड़ने का था।

हमने अपने कंसोल एप्लिकेशन के App.config में पोस्टग्रेज के लिए सेटिंग्स भी पंजीकृत की हैं।

UnitFramework अनुभाग निर्दिष्ट डिफ़ॉल्ट कारखाना कारखाने के रूप में निर्दिष्ट करता है:

 <entityFramework> <!--<defaultConnectionFactory type="System.Data.Entity.Infrastructure.SqlConnectionFactory, EntityFramework" />--> <defaultConnectionFactory type="Npgsql.NpgsqlConnectionFactory, EntityFramework6.Npgsql" /> <providers> <provider invariantName="System.Data.SqlClient" type="System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer" /> <provider invariantName="Npgsql" type="Npgsql.NpgsqlServices, EntityFramework6.Npgsql" /> </providers> </entityFramework> 

DbProviderFactories अनुभाग में, नए प्रदाता का कारखाना पंजीकृत किया गया था:

 <system.data> <DbProviderFactories> <add name="Npgsql Data Provider" invariant="Npgsql" support="FF" description=".Net Framework Data Provider for Postgresql" type="Npgsql.NpgsqlFactory, Npgsql" /> </DbProviderFactories> </system.data> 

और तुरंत, उन्होंने कनेक्शन स्ट्रिंग में पोस्टग्रेज सर्वर के पते और सर्वर व्यवस्थापक की साख को निर्दिष्ट करके डेटाबेस को शुरू करने की कोशिश की। परिणाम निम्न पंक्ति है:

“सर्वर = लोकलहोस्ट; DataBase = TestPostgresDB; एकीकृत सुरक्षा = झूठी; उपयोगकर्ता आईडी = पोस्टग्रेज; पासवर्ड = पा $ $ w0rd ”

जैसा कि अपेक्षित था, मैनुअल ईएफ माइग्रेशन मोड के लिए धन्यवाद, इनिशियलाइज़ेशन पास नहीं हुआ, और वर्तमान मॉडल की डेटाबेस छवि को मिसमैच करने में त्रुटि हुई। नए प्रदाता के साथ प्राथमिक माइग्रेशन के निर्माण के लिए और Postgres पर डेटाबेस इनिशियलाइज़ेशन का परीक्षण करने के लिए, हमने अपने इन्फ्रास्ट्रक्चर कॉन्फ़िगरेशन को थोड़ा समायोजित किया।

सबसे पहले, हमने "ऑटो-माइग्रेशन" चालू किया - एक उपयोगी विकल्प अगर एक डेवलपर टीम में डोमेन मॉडल और ईएफ बुनियादी ढांचे में बदलाव करता है:

 public sealed class Configuration : DbMigrationsConfiguration<MyDbContext> { public Configuration() { AutomaticMigrationsEnabled = true; ContextKey = "Project.Infrastructure.MyDbContext"; } } 

दूसरे, हमने एक नया प्रदाता निर्दिष्ट किया जिसमें विरासत में मिली क्लास CreateDatabaseIfNotExists की आरंभ की गई विधि आरंभ करें, जहाँ हम माइग्रेशन शुरू करते हैं:

 public class DbInitializer : CreateDatabaseIfNotExists<MyDbContext> { public override void InitializeDatabase(MyDbContext context) { DbMigrator dbMigrator = new DbMigrator(new Configuration { //TargetDatabase = new DbConnectionInfo(context.Database.Connection.ConnectionString, "System.Data.SqlClient") TargetDatabase = new DbConnectionInfo(context.Database.Connection.ConnectionString, "Npgsql") }); // There some code for run migrations } } 

अगला, हमने तर्क के रूप में उसी कनेक्शन स्ट्रिंग के साथ फिर से अपना कंसोल एप्लिकेशन लॉन्च किया। इस बार, संदर्भ का प्रारंभ त्रुटियों के बिना हुआ, और हमारे डोमेन मॉडल सुरक्षित रूप से नए पोस्टग्रेज डेटाबेस में फिट होते हैं। नए डेटाबेस में "__MigrationHistory" लेबल दिखाई दिया, जिसमें पहले स्वचालित रूप से निर्मित प्रवास का एक रिकॉर्ड था।

संक्षेप में: हम एक नए प्रदाता को बिना किसी समस्या के एक मौजूदा परियोजना से जोड़ने में सक्षम थे, लेकिन साथ ही साथ प्रवासन तंत्र की सेटिंग्स को बदल दिया।

मैन्युअल माइग्रेशन मोड चालू करें

जैसा कि ऊपर उल्लेख किया गया है, जब स्वचालित माइग्रेशन मोड चालू होता है, तो आप अपनी टीम को डोमेन और डेटा एक्सेस क्षेत्रों में समानांतर विकास से वंचित करते हैं। हमारे लिए, यह विकल्प अस्वीकार्य था। इसलिए, हमें परियोजना में पलायन का एक मैनुअल मोड स्थापित करने की आवश्यकता है।

सबसे पहले, हमने AutomaticMigrationsEnabled फ़ील्ड को गलत पर लौटाया। तब नए पलायन के निर्माण से निपटना आवश्यक था। हमने समझा कि अलग-अलग डीबीएमएस के लिए माइग्रेशन, कम से कम, अलग-अलग प्रोजेक्ट फ़ोल्डर में संग्रहीत किया जाना चाहिए। इसलिए, हमने PostgresMigrations नामक एक इन्फ्रास्ट्रक्चर प्रोजेक्ट में पोस्टग्रेज माइग्रेशन के लिए एक नया फ़ोल्डर बनाने का निर्णय लिया (स्पष्टता के लिए MsSql माइग्रेशन वाला फ़ोल्डर, हमने इसे MsSqlMigrations नाम दिया), और MsSql माइग्रेशन कॉन्फ़िगरेशन फ़ाइल की प्रतिलिपि बनाई। उसी समय, हमने PostgresSql के सभी मौजूदा MsSql माइग्रेशन की प्रतिलिपि नहीं की। सबसे पहले, क्योंकि उन सभी में MsSql प्रदाता के लिए कॉन्फ़िगरेशन का एक स्नैपशॉट होता है और, तदनुसार, हम उन्हें नए DBMS पर उपयोग करने में सक्षम नहीं होंगे। दूसरे, परिवर्तनों का इतिहास नए DBMS के लिए महत्वपूर्ण नहीं है, और हम डोमेन मॉडल की स्थिति के नवीनतम स्नैपशॉट के साथ प्राप्त कर सकते हैं।

हमने सोचा कि पोस्टग्रेज के पहले प्रवास के गठन के लिए सब कुछ तैयार था। स्वचालित माइग्रेशन मोड के साथ संदर्भ के प्रारंभ के दौरान बनाया गया डेटाबेस हटा दिया गया था। और, इस तथ्य से निर्देशित कि पहले प्रवास के लिए आपको डोमेन मॉडल की वर्तमान स्थिति के आधार पर एक भौतिक डेटाबेस बनाने की आवश्यकता है, हमने पैकेज कनेक्शन कंसोल में अपडेट-डेटाबेस कमांड को केवल कनेक्शन स्ट्रिंग पैरामीटर निर्दिष्ट करते हुए खुशी से बनाया। परिणामस्वरूप, हमें DBMS से जुड़ने से संबंधित एक त्रुटि मिली।

अतिरिक्त रूप से अद्यतन-डेटाबेस कमांड के कार्य सिद्धांत का अध्ययन करने के बाद, हमने निम्नलिखित कार्य किए:

• माइग्रेशन कॉन्फ़िगरेशन सेटिंग्स में निम्न कोड जोड़ा गया:
  
  MsSql के लिए:
  
  

   public Configuration() { AutomaticMigrationsEnabled = false; ContextKey = "Project.Infrastructure.MyDbContext"; MigrationsDirectory = @"MsSqlMigrations"; } 

  
  पोस्टग्रेज के लिए:
  
  

   public Configuration() { AutomaticMigrationsEnabled = false; ContextKey = "Project.Infrastructure.MyDbContext"; MigrationsDirectory = @"PostgresMigrations"; } 

• प्रदाता के नाम से अपडेट-डेटाबेस कमांड के आवश्यक पैरामीटर को इंगित किया
• जोड़े गए पैरामीटर जो प्रोजेक्ट को इंगित करते हैं जिसमें एफ़ई अवसंरचना का वर्णन है, और नए प्रदाता के माइग्रेशन कॉन्फ़िगरेशन वाला फ़ोल्डर

परिणामस्वरूप, हमें यह आदेश मिला:

Update-Database -ProjectName "Project.Infrastructure" -ConfigurationTypeName Project.Infrastructure.PostgresMigrations.Configuration -ConnectionString "Server = localhost; DataBase = TestPostgresDB; एकीकृत सुरक्षा = झूठी; उपयोगकर्ता आईडी = पोस्टग्रेज; पासवर्ड = पा $ $ w0rd "-ConnectionProviderName" Npgsql "

इस कमांड को निष्पादित करने के बाद, हम पहले माइग्रेशन का नामकरण के साथ एड-माइग्रेशन कमांड को समान मापदंडों के साथ निष्पादित करने में सक्षम थे:

ऐड-माइग्रेशन -Name "InitialCreate" -ProjectName "CrossTech.DSS.Infrastructure" -ConfigurationTypeName CrossTech.DSS.Infrastructure.PostgresMigrations .Configuration -ConnectionString "Server = localhost; DataBase = TestPostgresDB; एकीकृत सुरक्षा = झूठी; उपयोगकर्ता आईडी = पोस्टग्रेज; पासवर्ड = पा $ $ w0rd "-ConnectionProviderName" Npgsql "

PostgresMigrations फ़ोल्डर में एक नई फ़ाइल दिखाई दी है: 201701012070506868_InitialCreate.cs

फिर हमने अपडेट-डेटाबेस कमांड को निष्पादित करने के बाद बनाए गए डेटाबेस को हटा दिया और हमारे कंसोल एप्लिकेशन को एक तर्क के रूप में ऊपर दिए गए कनेक्शन स्ट्रिंग के साथ लॉन्च किया। और इसलिए हमें मैन्युअल रूप से बनाए गए माइग्रेशन के आधार पर पहले ही डेटाबेस मिल गया।

संक्षेप में: हम पोस्टग्रेज प्रदाता के लिए पहले माइग्रेशन को जोड़ने और कंसोल एप्लिकेशन के माध्यम से संदर्भ को आरंभ करने के लिए न्यूनतम प्रयास के साथ सक्षम थे, नया डेटाबेस प्राप्त कर रहे थे जिसमें हमारे पहले मैनुअल माइग्रेशन से परिवर्तन आए थे।

प्रदाताओं के बीच स्विच करें

हमारे पास अभी भी एक खुला सवाल था: संदर्भ आरंभीकरण को कैसे कॉन्फ़िगर किया जाए ताकि रनटाइम में एक विशिष्ट DBMS तक पहुंच संभव हो?

कार्य यह था कि संदर्भ के प्रारंभिक चरण में वांछित प्रदाता के एक या किसी अन्य लक्ष्य डेटाबेस का चयन करना संभव था। इस स्विच को बार-बार कॉन्फ़िगर करने के प्रयासों के परिणामस्वरूप, हम एक समाधान के साथ आए जो इस तरह दिखता है।

App.config (और यदि आप app.config, तब machine.config का उपयोग नहीं करते हैं) में प्रोजेक्ट के कंसोल एप्लिकेशन में, हम प्रदाता और कनेक्शन के नाम के साथ एक नया कनेक्शन स्ट्रिंग जोड़ते हैं, और संदर्भ निर्माता में हम कनेक्शन स्ट्रिंग के बजाय कनेक्शन नाम "ड्रॉप" करते हैं। उसी समय, हम DbConfiguration उदाहरण के सिंगलटन के माध्यम से कनेक्शन स्ट्रिंग को संदर्भ से कनेक्ट करते हैं। हम एक पैरामीटर के रूप में DbConfiguration से विरासत में मिली कक्षा का उदाहरण देते हैं।

परिणामस्वरूप वंशानुगत DbConfiguration वर्ग:

 public class DbConfig : DbConfiguration { public DbConfig(string connectionName, string connectionString, string provideName) { ConfigurationManager.ConnectionStrings.Add(new ConnectionStringSettings(connectionName, connectionString, provideName)); switch (connectionName) { case "PostgresDbConnection": this.SetDefaultConnectionFactory(new NpgsqlConnectionFactory()); this.SetProviderServices(provideName, NpgsqlServices.Instance); this.SetProviderFactory(provideName, NpgsqlFactory.Instance); break; case "MsSqlDbConnection": this.SetDefaultConnectionFactory(new SqlConnectionFactory()); this.SetProviderServices(provideName, SqlProviderServices.Instance); this.SetProviderFactory(provideName, SqlClientFactory.Instance); this.SetDefaultConnectionFactory(new SqlConnectionFactory()); break; } } } 

और संदर्भ इनिशियलाइज़ेशन अब इस तरह दिखता है:

 var connectionName = args[0]; var connectionString = args[1]; var provideName = args[2]; DbConfiguration.SetConfiguration(new DbConfig(connectionName, connectionString, provideName)); using (var context = MyDbContext(connectionName)) { Console.WriteLine("Database created"); } 

और जिसने ध्यान से पीछा किया, उसने शायद देखा कि हमें कोड में एक और बदलाव करना था। यह डेटाबेस इनिशियलाइज़ेशन के दौरान टारगेट डेटाबेस की परिभाषा है, जो पहले बताई गई InitializeDatabase विधि में होता है।

हमने किसी विशेष प्रदाता के माइग्रेशन कॉन्फ़िगरेशन को निर्धारित करने के लिए एक सरल स्विच जोड़ा:

 public class DbInitializer : CreateDatabaseIfNotExists<MyDbContext> { private string _connectionName; public DbInitializer(string connectionName) { _connectionName = connectionName; } public override void InitializeDatabase(MyDbContext context) { DbMigrationsConfiguration<MyDbContext> config; switch (_connectionName) { case "PostgresDbConnection": config = new PostgresMigrations.Configuration(); break; case "MsSqlDbConnection": config = new MsSqlMigrations.Configuration(); break; default: config = null; break; } if (config == null) return; config.TargetDatabase = new DbConnectionInfo(_connectionName); DbMigrator dbMigrator = new DbMigrator(config); // There some code for run migrations } } 

और संदर्भ निर्माता खुद इस तरह दिखने लगे:

 public MyDbContext(string connectionNameParam) : base(connectionString) { Database.SetInitializer(new DbInitializer(connectionName = connectionNameParam)); Database.Initialize(true); } 

अगला, हमने कंसोल एप्लिकेशन लॉन्च किया और MsSql एप्लिकेशन पैरामीटर को DBMS प्रदाता के रूप में निर्दिष्ट किया। हम आवेदन के लिए तर्क निम्नानुसार निर्धारित करते हैं:

"MsSqlDbConnection" "सर्वर = localhost \ SQLEXPRESS; डेटाबेस = TestMsSqlDB; उपयोगकर्ता आईडी = सा; पासवर्ड = पा $ $ w0rd "" System.Data.SqlClient "

MsSql डेटाबेस त्रुटियों के बिना बनाया गया था।

फिर हमने आवेदन तर्कों को निर्दिष्ट किया:

"PostgresDbConnection" "सर्वर = लोकलहोस्ट; DataBase = TestPostgresDB; एकीकृत सुरक्षा = झूठी; उपयोगकर्ता आईडी = पोस्टग्रेज; पासवर्ड = पा $ $ w0rd "" Npgsql "

पोस्टग्रेज डेटाबेस भी त्रुटियों के बिना बनाया गया था।

इसलिए, एक और उप-योग - ईएफ के लिए एक विशिष्ट प्रदाता के लिए डेटाबेस संदर्भ को इनिशियलाइज़ करने के लिए, रनटाइम में आपको आवश्यकता होती है:

• इस प्रदाता के लिए माइग्रेशन तंत्र "इंडिकेट" करें
• संदर्भ आरंभीकरण से पहले DBMS कनेक्शन तार कॉन्फ़िगर करें

हम एक टीम में दो DBMS के माइग्रेशन के साथ काम करते हैं

जैसा कि हमने देखा, सबसे दिलचस्प हिस्सा डोमेन में नए परिवर्तनों की उपस्थिति के बाद शुरू होता है। आपको एक विशिष्ट प्रदाता को ध्यान में रखते हुए दो DBMS के लिए माइग्रेशन उत्पन्न करना होगा।

तो, MSSQL सर्वर के लिए, आपको अनुक्रमिक कमांड निष्पादित करने की आवश्यकता है (पोस्टग्रेज के लिए, ऊपर वर्णित कमांड्स, जब पहला माइग्रेशन बनाते समय):

• अंतिम स्नैपशॉट के अनुसार डेटाबेस को अपडेट करना
  

  अद्यतन-डेटाबेस -ProjectName "Project.Infrastructure" -ConfigurationTypeName Project.Infrastructure.MsSqlMigrations.Configuration -ConnectionString "Server = localhost; DataBase = TestMsSqlDB; एकीकृत सुरक्षा = झूठी; उपयोगकर्ता आईडी = सा; पासवर्ड = पा $ $ w0rd "-ConnectionProviderName" System.Data.SqlClient "

• नया माइग्रेशन जोड़ना
  

  ऐड-माइग्रेशन -नाम "SomeMigrationName" -ProjectName "Project.Infrastructure" -ConfigurationTypeName Project.Infrastructure.MsSqlMigrations.Configuration -ConnectionString "Server = localhost; DataBase = TestMsSqlDB; एकीकृत सुरक्षा = झूठी; उपयोगकर्ता आईडी = सा; पासवर्ड = पा $ $ w0rd "-ConnectionProviderName" System.Data.SqlClient "

जब डेवलपर्स समानांतर में डोमेन में परिवर्तन करते हैं, तो संस्करण नियंत्रण प्रणाली में इन परिवर्तनों को मर्ज करने के लिए हमें कई संघर्ष होते हैं (सादगी के लिए जिसे हम गिट कहेंगे)। यह इस तथ्य के कारण है कि ईएफ के लिए पलायन एक के बाद एक क्रमिक रूप से चलते हैं। और अगर एक डेवलपर एक माइग्रेशन बनाता है, तो एक और डेवलपर बस माइग्रेशन को क्रमिक रूप से जोड़ने में सफल नहीं होगा। प्रत्येक बाद के प्रवासन पिछले एक के बारे में जानकारी संग्रहीत करता है। इस प्रकार, माइग्रेशन में तथाकथित मॉडल स्नैपशॉट को अंतिम बनाए गए के लिए अपडेट करना आवश्यक है।

इसी समय, किसी विशेष डेवलपर के परिवर्तनों के महत्व को प्राथमिकता देने के लिए एक टीम में ईएफ माइग्रेशन पर संघर्षों को हल करना नीचे आता है। और जिनके परिवर्तन प्राथमिकता में अधिक हैं, उन लोगों को उन्हें भरने के लिए सबसे पहले होना चाहिए, और सहमत पदानुक्रम के अनुसार बाकी डेवलपर्स निम्नलिखित करने की आवश्यकता है:

1. हटाए गए स्थानीय माइग्रेशन हटाएं
2. रिपॉजिटरी से स्वयं में परिवर्तन खींचो, जहां एक उच्च प्राथमिकता वाले अन्य सहयोगियों ने पहले से ही अपना पलायन डाला है
3. स्थानीय माइग्रेशन बनाएं और परिणामी परिवर्तनों को वापस git पर अपलोड करें

जहां तक ​​हम ईएफ माइग्रेशन तंत्र से परिचित हैं, हम अनुमान लगा सकते हैं कि वर्णित टीम विकास दृष्टिकोण इस समय एकमात्र है। हम इस समाधान को आदर्श नहीं मानते हैं, लेकिन इसे जीवन का अधिकार है। और ईएफ माइग्रेशन तंत्र का विकल्प खोजने का सवाल हमारे लिए जरूरी हो गया है।

निष्कर्ष में

EF6 का उपयोग करते हुए EF6 के साथ संयोजन में कई DBMS के साथ काम करना वास्तविक है, लेकिन इस संस्करण में Microsoft के लोगों ने संस्करण नियंत्रण प्रणालियों का उपयोग करके टीम के समानांतर काम की संभावना को ध्यान में नहीं रखा।

बाजार पर कई वैकल्पिक ईएफ माइग्रेशन समाधान हैं (भुगतान और मुक्त दोनों): डीबीयूपी, राउंडहोस, थिंकिंगहोम।निग्रेटर, फ्लुएंटमिगेटर, आदि। और समीक्षाओं को देखते हुए, वे ईएफ माइग्रेशन की तुलना में डेवलपर्स को अधिक पसंद करते हैं।

सौभाग्य से, अब हमारे पास अपनी परियोजना में किसी प्रकार का उन्नयन करने का अवसर है। और निकट भविष्य में हम EF Core में बदल जाएंगे। हमने ईएफ कोर माइग्रेशन तंत्र के पेशेवरों और विपक्षों को तौला और इस निष्कर्ष पर पहुंचे कि यह हमारे लिए तीसरे पक्ष के समाधान के साथ काम करने के लिए अधिक सुविधाजनक होगा, अर्थात् फ्लुएंट माइग्रेटर।

हमें उम्मीद है कि आप हमारे अनुभव में रुचि रखते थे। टिप्पणियों को स्वीकार करने और सवालों के जवाब देने के लिए तैयार हैं, वेलकम!