🎲 🤱🏿 👨‍❤️‍👨 LINQ का उपयोग कर डेटाबेस से DTO निकालने के लिए एक तंत्र का विकास 🛍️ 🌰 🆗

समस्या का बयान

इस लेख में मैं हमारी कंपनी के एक प्रोजेक्ट में कार्यान्वित डीटीओ निर्माण तंत्र का वर्णन करूँगा। परियोजना में एक सर्वर भाग और कई क्लाइंट (सिल्वरलाइट, आउटलुक, आईपैड) शामिल हैं। सर्वर WCF पर कार्यान्वित सेवाओं की एक श्रृंखला है। चूंकि सेवाएं हैं, आपको उनके साथ कुछ डेटा का आदान-प्रदान करने की आवश्यकता है। विकल्प, जब ग्राहकों को डोमेन डोमेन संस्थाओं के बारे में पता होता है और उन्हें सर्वर से प्राप्त होता है, तो कई कारणों से तुरंत गायब हो गया है:

सभी क्लाइंट .NET पर लागू नहीं होते हैं।
जटिल वस्तु रेखांकन के लिए संभावित क्रमांकन समस्याएं
डेटा अतिरेक

सिद्धांत रूप में, ये सभी कमियां लंबे समय से ज्ञात हैं, और स्मार्ट लोग उन्हें ठीक करने के लिए डेटा ट्रांसफर ऑब्जेक्ट (डीटीओ) पैटर्न के साथ आए थे। अर्थात्, डोमेन डोमेन इकाई वर्ग केवल सर्वर के लिए जाना जाता है, जबकि ग्राहक डीटीओ कक्षाओं और सेवाओं के साथ समान कक्षाओं के एक्सचेंज इंस्टेंस के साथ काम करते हैं। सिद्धांत रूप में, सब कुछ ठीक है, व्यवहार में, दूसरों के बीच, डीटीओ बनाने और उनमें संस्थाओं से डेटा रिकॉर्ड करने के सवाल हैं। छोटी परियोजनाओं में, = ऑपरेटर इस काम के साथ ठीक काम करेगा। लेकिन, जब परियोजना का आकार बढ़ना शुरू हो जाता है और कोड वृद्धि के प्रदर्शन और स्थिरता के लिए आवश्यकताएं होती हैं, तो अधिक लचीले समाधान की आवश्यकता बढ़ जाती है। नीचे मैं उस तंत्र के विकास का वर्णन करूंगा जिसका उपयोग हम डीटीओ बनाने और आबाद करने के लिए करते हैं।

डोमेन मॉडल उदाहरण

अधिक चित्रण चित्रण के लिए, हम एक परीक्षण डोमेन मॉडल को परिभाषित करते हैं। मान लीजिए हमारा आवेदन उल्कापिंडों पर नज़र रखता है। हमारे पास मुख्य प्रकार हैं:

/// <summary> ///    . /// </summary> public class Entity { /// <summary> /// . /// </summary> public Guid Id { get; set; } } /// <summary> ///   . /// </summary> public abstract class Meteor: Entity { /// <summary> /// . /// </summary> public string Name { get; set; } /// <summary> /// . /// </summary> public double Weight { get; set; } /// <summary> ///     . /// </summary> public Material Material { get; set; } /// <summary> ///   . /// </summary> public double DistanceToEarth { get; set; } /// <summary> ///   . /// </summary> public RiskLevel RiskLevel { get; set; } } /// <summary> ///  . /// </summary> public class SpaceMeteor: Meteor { /// <summary> /// / . /// </summary> public DateTime DetectedAt { get; set; } /// <summary> ///  . /// </summary> public Person DetectingPerson { get; set; } /// <summary> /// ,   . /// </summary> public Galaxy PlaceOfOrigin { get; set; } } /// <summary> ///   . /// </summary> public class ArtificialMeteor: Meteor { /// <summary> /// -. /// </summary> public Country Country { get; set; } /// <summary> /// -. /// </summary> public SecretFactory Maker { get; set; } /// <summary> ///  . /// </summary> public string SerialNumber { get; set; } /// <summary> ///  . /// </summary> public Person QualityEngineer { get; set; } }

संबंधित डोमेन कक्षाओं के लिए, हम डीटीओ कक्षाएं बनाते हैं। यह ध्यान दिया जाना चाहिए कि हमारी परियोजना में हम पूरी तरह से फ्लैट डीटीओ का उपयोग करते हैं।

 /// <summary> ///    DTO. /// </summary> public class BaseDto { public Guid Id { get; set; } } /// <summary> ///   DTO . /// </summary> public abstract class MeteorDto: BaseDto { public string Name { get; set; } public double Weight { get; set; } public string MaterialName { get; set; } public Guid? MaterialId { get; set; } public double DistanceToEarth { get; set; } public string RiskLevelName { get; set; } public Guid RiskLevelId { get; set; } } /// <summary> /// DTO  . /// </summary> public class SpaceMeteorDto: MeteorDto { public DateTime DetectedAt { get; set; } public string DetectingPersonName { get; set; } public Guid DetectingPersonId { get; set; } public string PlaceOfOriginName { get; set; } public Guid? PlaceOfOriginId { get; set; } } /// <summary> /// DTO   . /// </summary> public class ArtificialMeteorDto: MeteorDto { public string CountryName { get; set; } public Guid CountryId { get; set; } public string MakerName { get; set; } public string MakerAddress { get; set; } public string MakerDirectorName { get; set; } public Guid MakerId { get; set; } public string SerialNumber { get; set; } public string QualityEngineerName { get; set; } public Guid QualityEngineerId { get; set; } }

तंत्र संख्या 1 - डेटाबेस से एक इकाई, फिर इकाई से डीटीओ

समस्या के लिए पहला दृष्टिकोण एक इंटरफ़ेस बनाने के परिणामस्वरूप हुआ

 interface IDtoMapper<TEntity, TDto> { IEnumerable<TDto> Map(IEnumerable<TEntity> entities); }

प्रत्येक इकाई-डीटीओ जोड़ी के लिए, एक वर्ग बनाया गया था जो एक इंटरफ़ेस को लागू करता है जो संबंधित प्रकारों द्वारा बंद किया जाता है। मैपिंग को ऑटोमैपर के माध्यम से लागू किया गया था, जिसने हमें संपत्तियों के नियमित असाइनमेंट से छुटकारा पाने की अनुमति दी और केवल उन मामलों का स्पष्ट रूप से वर्णन किया जब संपत्तियों का नाम ऑटोमैपर द्वारा उपयोग किए गए समझौते के तहत नहीं आया था। यह कैसे काम किया:

एक ग्राहक एक डेटासेट को पुनः प्राप्त करने के लिए WCF ऑपरेशन कहता है
कुछ मानदंडों के अनुसार संस्थाओं को डेटाबेस से डाउनलोड किया जाता है और IDtoMapper पर स्थानांतरित किया जाता है
IDtoMapper DTO इंस्टेंस बनाता है और संस्थाओं से DTO के डेटा की प्रतिलिपि बनाता है।
एक DTO संग्रह ग्राहक को लौटाया जाता है।

इस तंत्र ने काम किया और हम तब तक काफी खुश थे, जब बढ़ते भार के साथ, प्रदर्शन की समस्याएं दिखाई दीं। मापों से पता चला है कि दोषियों में से एक पुराने IDtoMapper था। (हमने उसे डांटा नहीं, क्योंकि एजाइल की सर्वश्रेष्ठ परंपराओं में उसने उत्पाद को जल्दी से मुक्त करने, काम के दौरान इसे बेहतर ढंग से समझने और फिर प्राप्त अनुभव के आधार पर अलग-अलग हिस्सों को फिर से लिखने में हमारी मदद की।) समस्या यह थी कि डेटाबेस से अधिक डेटा निकाला गया था। डीटीओ में भरना आवश्यक था। वस्तुओं के बीच संघों और एकत्रीकरण ने बड़ी संख्या में जुड़ाव का नेतृत्व किया, जिसने सिस्टम की गति को नकारात्मक रूप से प्रभावित किया।

हमने समस्या को हल करने के लिए 2 विकल्पों पर विचार किया: डेटा निष्कर्षण रणनीतियों (आलसी या उत्सुक लोडिंग, आदि) के साथ संयोजन, या डेटाबेस से सीधे डीटीओ निकालें। दूसरा रास्ता सबसे सरल, उत्पादक और लचीला चुना गया। यहाँ यह ध्यान दिया जाना चाहिए कि हम NHibernate का उपयोग ORM के रूप में करते हैं, डेटाबेस क्वेरीज़ LINQ के माध्यम से बनाई जाती हैं। निम्नलिखित सभी भी इकाई ढांचे में काम करेंगे।

तंत्र संख्या 2 - डेटाबेस से डीटीओ

निम्नलिखित इंटरफ़ेस बनाया गया था:

 interface IDtoFetcher<TEntity, TDto> { IEnumerable<TDto> Fetch(IQueryable<TEntity> query, Paging paging, FetchAim fetchAim); }

अब विधि एक के बजाय 3 मापदंडों को स्वीकार करती है:

क्वेरी - इकाई प्रकार से LINQ क्वेरी
पेजिंग - निकाले गए पृष्ठ के बारे में जानकारी
fetchAim - निष्कर्षण लक्ष्य

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

 /// <summary> ///   DTO. /// </summary> public enum FetchAim { /// <summary> ///    /// </summary> None, /// <summary> ///  /// </summary> Card, /// <summary> ///  /// </summary> List, /// <summary> ///  /// </summary> Index }

अमूर्तन की पहचान, यह इसके कार्यान्वयन की बारी थी। SQL में चुनिंदा फ़ील्ड्स के लिए, प्रक्षेपण का उपयोग किया जाता है, उदाहरण के लिए:

 SELECT (id, name) FROM meteors

LINQ में, अनुमानों का चयन () विधि का उपयोग करके किया जाता है। निम्न LINQ क्वेरी निष्पादित करते समय उपरोक्त SQL क्वेरी उत्पन्न होगी:

 IQueryable<Meteor> meteorQuery = _meteorRepository.Query(); IEnumerable<MeteorDto> meteors = meteorQuery .Select(m => new MeteorDto { Id = m.Id, Name = m.Name }) .ToList();

इस LINQ क्षमता के बारे में जानने के बाद, हमने IDtoFetcher के विशिष्ट कार्यान्वयन बनाने के लिए कड़ी मेहनत करना शुरू किया:

 class SpaceMeteorDtoFetcher: IDtoFetcher<SpaceMeteor, SpaceMeteorDto> { public IEnumerable<SpaceMeteorDto> Fetch(IQueryable<SpaceMeteor> query, Page page, FetchAim fetchAim) { if (fetchAim == FetchAim.Index) { return query .Select(m => new SpaceMeteorDto { Id = m.Id, Name = m.Name }) .Page(page) .ToList(); } else if (fetchAim == FetchAim.List) { // ... } // ... } }

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

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

कार्यान्वयन

कार्यान्वयन के साथ परियोजना का स्रोत कोड (.NET 4.0, NHibernate 3.3.2, विजुअल स्टूडियो 2012) यहाँ है ।

यह समझने के लिए कि हमें अभिव्यक्ति के पेड़ों के साथ एक असमान संघर्ष में क्यों प्रवेश करना था, मैं एक उदाहरण दूंगा कि किसी विशेष वर्ग के लिए भ्रूण का विन्यास अब कैसे किया जाता है।

 /// <summary> ///  DTO  . /// </summary> public class SpaceMeteorDtoFetcher: BaseMeteorDtoFetcher<SpaceMeteor, SpaceMeteorDto> { static SpaceMeteorDtoFetcher() { CreateMapForIndex(); CreateMapForList(); CreateMapForCard(); } private static void CreateMapForIndex() { var map = CreateFetchMap(FetchAim.Index); //       MapBaseForIndex(map); } private static void CreateMapForList() { var map = CreateFetchMap(FetchAim.List); //       MapBaseForList(map); MapSpecificForList(map); } /// <summary> ///       . /// </summary> /// <param name="map">   </param> private static void MapSpecificForList(IFetchMap<SpaceMeteor, SpaceMeteorDto> map) { map.Map(d => d.DetectedAt, e => e.DetectedAt) .Map(d => d.DetectingPersonName, e => e.DetectingPerson.FullName) .Map(d => d.PlaceOfOriginName, e => e.PlaceOfOrigin.Name); } private static void CreateMapForCard() { var map = CreateFetchMap(FetchAim.Card); MapBaseForCard(map); MapSpecificForCard(map); } /// <summary> ///       . /// </summary> /// <param name="map">   </param> private static void MapSpecificForCard(IFetchMap<SpaceMeteor, SpaceMeteorDto> map) { map.Map(d => d.DetectedAt, e => e.DetectedAt) .Map(d => d.DetectingPersonId, e => e.DetectingPerson.Id) .Map(d => d.PlaceOfOriginId, e => e.PlaceOfOrigin.Id); } public SpaceMeteorDtoFetcher(IRepository repository) : base(repository) { } }

मानचित्रण अमूर्त का उपयोग भ्रूण को कॉन्फ़िगर करने के लिए किया जाता है।

 public interface IFetchMap<TSource, TTarget> where TSource : Entity where TTarget : BaseDto { /// <summary> ///          DTO. /// </summary> IFetchMap<TSource, TTarget> Map<TProperty>( Expression<Func<TTarget, TProperty>> targetProperty, Expression<Func<TSource, TProperty>> sourceProperty); /// <summary> ///       DTO,      . /// </summary> IFetchMap<TSource, TTarget> CustomMap(Action<IQueryable<TSource>, IEnumerable<TTarget>> fetchOperation); }

कॉन्फ़िगरेशन कैसे होता है: हम एक विशिष्ट निष्कर्षण उद्देश्य के लिए एक मैपिंग ऑब्जेक्ट बनाते हैं, यह इंगित करने के लिए मैप विधियों को कॉल करते हैं कि डेटाबेस से कौन से गुण लोड किए जाने चाहिए। CustomMap विधि का उपयोग एक विस्तार बिंदु के रूप में किया जाता है - वहां पारित प्रतिनिधि में, हम डेटाबेस से मैन्युअल रूप से डेटा लोड करने और इसे निकाले गए DTO को लिखने के लिए तर्क निर्दिष्ट कर सकते हैं।

DTO उल्कापिंड का आधार वर्ग Fetcher BaseMeteorDtoFetcher आधार वर्ग के गुणों की मैपिंग के लिए तरीके प्रदान करता है - इस तरह हम दोहराव से बचते हैं और नए प्रकार के उल्कापिंडों के लिए भ्रूण के निर्माण को गति देते हैं। BaseMeteorDtoFetcher स्वयं, बदले में, BaseDtoFetcher से विरासत में मिला है, जो कि IFetchMap प्रकार की बनाई गई वस्तुओं का संग्रह संग्रहीत करता है और DTO को पुनः प्राप्त करने के लिए उनका उपयोग करता है।

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

निष्कर्ष

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

मुझे उम्मीद है कि ऊपर वर्णित अनुभव कुछ पाठकों को परियोजना के कार्यान्वयन के दौरान सुरक्षित रूप से एकत्र किए गए रेक के आसपास प्राप्त करने की अनुमति देगा। और अगर कोई जानता है कि यह सब कैसे आसान और अधिक लचीला महसूस किया जा सकता है, तो मुझे इसके बारे में सुनकर खुशी होगी। आपका ध्यान के लिए धन्यवाद!