सॉफ्टवेयर विकास की प्रक्रिया में, जब सभी कार्यक्षमता को अंततः परिभाषित नहीं किया जाता है, तो डेटाबेस संरचना अक्सर बदल जाती है। और यदि कोई ORM- फ्रेमवर्क का उपयोग किया जाता है, तो डेटा मॉडल बदलने के बाद डेटाबेस को बदलने से कुछ असुविधा होती है (वास्तव में, आपको मॉडल वर्ग और डेटाबेस संरचना को बदलने के लिए दोहरा काम करने की आवश्यकता है)। संक्षेप में, पैकेज मैनेजर कंसोल का उपयोग करके
EF 4 कोड फर्स्ट में माइग्रेशन कैसे किया जाता
है , इसका वर्णन
यहां किया गया
है , लेकिन मैं यह वर्णन करने की कोशिश करूंगा कि डेवलपर की भागीदारी के बिना ऑटोमैटिक माइग्रेशन कैसे काम करता है (अधिक सटीक, न्यूनतम भागीदारी के साथ)।
यह सब कैसे शुरू हुआ
कार्य एक नई परियोजना बनाना था, जो एक
AWP की तरह है।
कॉन्फ्रेंस करने के बाद, हमने एंटिटी फ्रेमवर्क कोड फर्स्ट का उपयोग करने का फैसला किया, क्योंकि भविष्य में,
DBMS को बदलना संभव है, और इस विकल्प के साथ हमें बस कनेक्शन स्ट्रिंग को बदलने की आवश्यकता होगी (यदि उपयुक्त ADO.NET प्रदाता है)।
हमने डेटा मॉडल बनाए, DbContext से विरासत में मिला एक संदर्भ वर्ग:
public class ProjectContext : DbContext { public ProjectContext() { } public ProjectContext(string connString) : base(connString) { } public DbSet<Address> Addresses { get; set; } ... }
जोड़ा इनिशियलाइज़र:
public class ProjectInitializer : DropCreateDatabaseIfModelChanges<ProjectContext> { protected override void Seed(ProjectContext context) { ... } }
और लिखना (Global.asax में हमारे मामले में) इनिशलाइज़र:
Database.SetInitializer(new ProjectInitializer());
सब कुछ अद्भुत लगता है, जिसके पास इसे बनाने के लिए आधार नहीं है, लेकिन ग्राहक के साथ विवरण को स्पष्ट करने के बाद, अधिक संस्थाओं को जोड़ना आवश्यक हो गया। और चूंकि कई डेवलपर्स विकसित हो रहे हैं, डेटाबेस का एक बड़ा मनोरंजन हुआ और वहां डेटा पहले से ही वास्तविक था।
प्रवास
इसलिए हम प्रवास पर आए। सलाह के अनुसार,
लेख ने पैकेज मैनेजर कंसोल में कमांड को निष्पादित किया:
PM> Add-Migration 1
माइग्रेशन फ़ोल्डर प्रोजेक्ट में दिखाई दिया, जिसमें दो फ़ाइलें बनाई गई थीं: कॉन्फ़िगरेशन .cs, <date_time> _1.cs। पहला, जैसा कि नाम से पता चलता है, माइग्रेशन कॉन्फ़िगरेशन है, दूसरे में संस्करण को अपडेट / रोलबैक करने के लिए आवश्यक डेटाबेस परिवर्तन शामिल हैं। अगला, बस NuGet के कंसोल में निष्पादित करें:
PM> Update-Database
सब कुछ अद्भुत था, अगर किसी का मॉडल डेटाबेस से मेल नहीं खाता है, तो उसने बस कंसोल में माइग्रेशन किया और फाइल को माइग्रेशन से हटा दिया। जब तक ग्राहक के सर्वर पर प्रोजेक्ट लगाने का समय आ गया है। NuGet वहां नहीं था, और या तो स्थापित करने का कोई अवसर नहीं था (और होस्टिंग प्रदाता के पास ऐसा अवसर है, सिद्धांत रूप में, यदि आप सर्वर नहीं लेते हैं)।
स्वचालित माइग्रेशन
IntelliSense के साथ सशस्त्र, माइग्रेशन विधि
का उपयोग करके स्वचालित माइग्रेशन कैसे किया जाता है, यह जानने की कोशिश करते
हुए , अनुभवजन्य विधि से पता चला कि आपको उस वर्ग को बदलने की आवश्यकता है जिसमें से आरम्भिक को विरासत में मिला है:
लॉन्च किया गया और इसे अपवाद मिला:
अहा! हम वह करते हैं जो अपवाद संदेश में प्रस्तावित है, जो है:
public sealed class Configuration : DbMigrationsConfiguration<ProjectContext> { public Configuration() { AutomaticMigrationsEnabled = true; } protected override void Seed(ProjectContext context) { } }
हम शुरू करते हैं और देखते हैं कि माइग्रेशन अपने आप होता है।
हमने वह हासिल किया जो हम चाहते थे, अब प्रवासी डेवलपर की भागीदारी के बिना होते हैं, लेकिन मैंने उल्लेख किया कि कुछ भागीदारी अभी भी आवश्यक है, उदाहरण के लिए, यदि आप मॉडल संपत्ति का नाम बदलकर परियोजना शुरू करते हैं, तो हम निम्नलिखित अपवाद देखेंगे:
तथ्य यह है कि, एंटिटी फ्रेमवर्क के दृष्टिकोण से, एक संपत्ति का नाम बदलना एक नए नाम के साथ हटा रहा है और जोड़ रहा है, और इस प्रकार डेटा हानि संभव है। ऐसे मामलों में (और उनमें से कुछ हैं), आपको बस ऐड-माइग्रेशन कमांड का उपयोग करके मैन्युअल रूप से माइग्रेशन बनाने की आवश्यकता है और मैन्युअल रूप से DropColumn और CreateColumn को RenameColumn (या स्थिति के आधार पर कुछ और,) में समायोजित करें।
निष्कर्ष
यह सब, मुझे उम्मीद है कि लेख उपयोगी होगा। और मुझे यह भी उम्मीद है कि इस मुद्दे पर मूल स्रोत से बहुत कम जानकारी है, क्योंकि यह एक प्रकार का बीटा संस्करण है और एंटिटी फ्रेमवर्क 5.0 की रिलीज के साथ, मुझे परीक्षण और त्रुटि द्वारा सही उपयोग के मामले की खोज नहीं करनी है।