🍞 😫 🏳️ उद्यम अनुप्रयोग विकास में ओआरएम का उपयोग करना 👨🏽‍🔬 👨🏽‍🔬 🐅

ओआरएम के पेशेवरों और विपक्षों के बारे में बहुत सारे विवाद हैं, चलो ईआरपी अनुप्रयोगों में इसका उपयोग करते समय पेशेवरों पर ध्यान देने की कोशिश करते हैं।

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

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

मैं CodeFirst दृष्टिकोण का समर्थक हूं, जैसा कि यह केवल व्यावसायिक अनुप्रयोग की संरचना की योजना बनाने के लिए सही है।
हमारे अंतिम मंच में, एक लंबे विकल्प के बाद, हमने ORM DataObjects.Net का उपयोग करने का निर्णय लिया, लेकिन लेख का सार किसी भी ORM के अनुयायी के लिए स्पष्ट होगा, यह NHibernate, Entity Framework, आदि हो।

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

डेटा मॉडल डिजाइन

एक मॉडल बनाने से सी # में कक्षाएं बना रहा है, फ़ील्ड गुण, विशेषताओं, टिप्पणियों को जोड़ रहा है।
एक रियल एस्टेट एजेंसी के लिए क्लास मॉडल

कोड में, यह कुछ इस तरह दिखता है:

/// <summary> ///    /// </summary> [HierarchyRoot] [Index("CreationTime", Clustered = true)] public abstract class RentOfferBase : DocumentBase { … /// <summary> ///  /// </summary> [Hidden] [Field(Length = 64)] public string Name { get; set; } /// <summary> ///   /// </summary> [Field] public DateTime CreationTime { get; set; } /// <summary> ///  /// </summary> [Field(Scale = 0)] public decimal Price { get; set; } /// <summary> ///  /// </summary> [Field(Scale = 0)] public decimal Comission { get; set; } /// <summary> ///  ///      /// </summary> [Field(Nullable = false)] public EnCurrency Currency { get; set; } /// <summary> ///  ///   /// </summary> [Field] public MetroLine Line { get; set; } /// <summary> ///  ///       /// </summary> [Field] public MetroStation Metro { get; set; } }

कुछ विशेषताएं जो इसे ध्यान देने के लिए समझ में आती हैं:

Xml टिप्पणियाँ
वे न केवल कोड की स्पष्टता के लिए बने हैं, बल्कि सिस्टम इंटरफ़ेस में उपयोग के लिए भी हैं। पहली पंक्ति पर जो है वह प्रदर्शित फ़ील्ड नाम होगा। सभी इस प्रकार एक टूलटिप है। इस दृष्टिकोण के साथ, हमने कोड प्रलेखन बनाए रखना और ऑब्जेक्ट नामों का प्रबंधन करना आसान बना दिया है।
गुण
```
 [Field(Length = 64)] 
```
फ़ील्ड - एक सामान्य संकेत है कि संपत्ति एक स्थिर संपत्ति होगी
लंबाई - लाइन की लंबाई
स्केल = 0 - दशमलव में दशमलव स्थानों की संख्या
```
 [Index("CreationTime", Clustered = true)] 
```
एक इकाई (वर्ग) का एक गुण सूचकांक, प्रमुख क्षेत्रों, प्रकार के निर्माण का संकेत देता है
```
 [HierarchyRoot] 
```
एक विशेषता यह दर्शाता है कि वर्ग इकाई पदानुक्रम की जड़ है, अर्थात। इस वर्ग और उसके वंशज दोनों के सभी उदाहरण संग्रहीत हैं

इस उदाहरण में, मैंने मकान मालिक (रेंटऑफ़रबेस) के प्रस्तावों के लिए विरासत लागू किया है - मूल प्रस्ताव में कुछ फ़ील्ड, अधिक विस्तृत ऑफ़र शामिल हैं, उदाहरण के लिए, अपार्टमेंट ऑफ़र - इसमें अर्हकारी फ़ील्ड - रसोई क्षेत्र, कमरों की संख्या शामिल है।

विरासत

ओआरएम के साथ काम करते समय, हम विरासत के रूप में इस तरह के एक शक्तिशाली ओओपी उपकरण का उपयोग कर सकते हैं।
किराये की पेशकश के आधार वर्ग के लिए, हम वारिस बनाते हैं: अपार्टमेंट ऑफ़र और रूम ऑफ़र

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

कैप्सूलीकरण

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

ClassTable

यह डिफ़ॉल्ट रूप से उपयोग किया जाता है, और पदानुक्रम की जड़ से शुरू होकर, प्रत्येक वर्ग के लिए एक तालिका बनाता है
ClassTable वंशानुक्रम मॉडल के लिए तालिका स्कीमा

SingleTable

सभी पदानुक्रम वर्गों के लिए एक तालिका
सिंगलटेबल इनहेरिटेंस मॉडल के लिए टेबल स्कीमा

ConcreteTable

प्रत्येक गैर-सार वर्ग के लिए तालिका के अनुसार
ठोस योजनाबद्ध मॉडल के लिए टेबल स्कीमा

यह सब क्यों जरूरी है?

कुछ मामलों में, सामान्यीकृत डेटा को संग्रहीत करना सुविधाजनक है, और दूसरों में, अनुकूलन के लिए, तालिकाओं को वंचित करना अधिक सुविधाजनक है। ओआरएम का लाभ यह है कि यह बहुत सरलता से किया जा सकता है - बस एक पंक्ति को बदलकर - हमारे मामले में

 [HierarchyRoot]

द्वारा प्रतिस्थापित किया जाएगा

 [HierarchyRoot(InheritanceSchema.SingleTable)]

और

 [HierarchyRoot(InheritanceSchema.ConcreteTable)]

क्रमशः। इसके अलावा, के बाद से चूँकि हम क्वेरीज़ SQL में नहीं लिख रहे हैं, इसलिए उपयुक्त इनहेरिटेंस स्कीम का उपयोग करने के लिए सभी प्रश्नों का स्वचालित रूप से अनुवाद किया जाएगा। यानी LINQ में लिखे और ORM के माध्यम से काम करने वाले किराये के प्रस्तावों / अपार्टमेंट / कमरों की एक रिपोर्ट प्रत्येक योजना के साथ काम करेगी और इसमें किसी भी संशोधन की आवश्यकता नहीं होगी।

व्यापार तर्क जोड़ना

प्रपत्र घटनाएँ

अधिकांश प्लेटफ़ॉर्म (जैसे हमारे) मॉडल के अनुसार स्वचालित रूप से फ़ॉर्म उत्पन्न कर सकते हैं। लेकिन हमारे पास पर्याप्त स्थिर रूप नहीं हैं, चलो इसे पुनर्जीवित करते हैं, गतिकी जोड़ते हैं। हमारी प्रणाली में, हमने एक फॉर्म इवेंट हैंडलर के रूप में इस तरह की अवधारणा पेश की - एक वर्ग जो एक हैंडलर इंटरफेस को लागू करता है जिसमें संकेत दिया जाता है कि कौन से फ़ील्ड घटनाओं से जुड़े हैं। क्लाइंट पर डेटा को बदलकर, डेटा को सर्वर पर भेजा जाता है, डिसेरिएलाइज़ेशन, .net ऑब्जेक्ट की प्रोसेसिंग, क्रमांकन, क्लाइंट को डेटा भेजते हैं।

उदाहरण के लिए, हम फॉर्म पर लागत को बदलते हैं, तुरंत, मक्खी पर, प्रतिशत पुनर्गणना होता है। और इसके विपरीत। और यहां बताया गया है कि कैसे यह कोड में दिखता है:

 /// <summary> ///    Price  ComissionPercent /// </summary> [OnFieldChange("Price", "ComissionPercent")] public class RentalPriceFormEvent : RentOfferFormEventsBase<RentOfferBase> { public override void OnFieldChange(RentOfferBase item) { if (item.ComissionPercent != decimal.Zero) { item.Comission = item.Price * 0.01m * item.ComissionPercent; } } }

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

बहुरूपता

पिछले उदाहरण में, हमने केवल एक RentOfferBase इकाई के लिए एक ईवेंट लिखा, यह ईवेंट वारिस के साथ काम करेगा, लेकिन क्या होगा यदि हमारे पास मूल्य / कमीशन के साथ कई संस्थाएं हैं? क्या आप हर बार एक ही कोड लिखते हैं?
एक इंटरफ़ेस चुनें

 /// <summary> ///   /// </summary> public interface IWithComission { /// <summary></summary> decimal Price { get; set; } /// <summary></summary> decimal Comission { get; set; } /// <summary>%</summary> decimal ComissionPercent { get; set; } }

और के रूप में घटना को फिर से लिखना

 /// <summary> ///    RentalPrice  ComissionPercent /// </summary> /// <typeparam name="TEntity"> </typeparam> [OnFieldChange("Price", "ComissionPercent")] public class RentalPriceFormEvent<TEntity> : RentOfferFormEventsBase<TEntity> where TEntity : DocumentBase, IWithComission { public override void OnFieldChange(TEntity item) { if (item.ComissionPercent != decimal.Zero) { item.Comission = item.Price * 0.01m * item.ComissionPercent; } } }

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

इकाई घटनाएँ

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

 /// <summary> ///       /// </summary> [FireOn(EntityEventAction.Updated)] public class CheckStatus<TEntity> : IEntityEvent<TEntity> where TEntity : EntityBase, IWithStatus { /// <summary> ///   /// </summary> /// <param name="item">    </param> public void Execute(TEntity item) { if (item.Status.Name == "" && !Roles.IsUserInRole("admin")) { throw new ErrorException("     ''!"); } } /// <summary> ///       /// </summary> public EntityEventAction CurrentAction { get; set; } }

जो यह जांचता है कि यदि परिवर्तनशील इकाई "बंद" स्थिति में है और उपयोगकर्ता व्यवस्थापक भूमिका से संबंधित नहीं है, तो एक अपवाद फेंक दिया गया है। इसी तरह से घटनाओं को बनाने के लिए, इकाई घटनाओं को उनके साथ संगत सभी संस्थाओं पर लागू किया जाएगा, इस मामले में IWithStatus इंटरफ़ेस को लागू करना।

कोड जुदाई

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

फिल्टर

ORM का उपयोग करने से आप ऐसे शक्तिशाली .net टूल का उपयोग कर सकते हैं, जैसे फ़िल्टरिंग के लिए एक्सप्रेशनट्रीस। हम व्यापार तर्क की सीमा के रूप में उपयोग के लिए अग्रिम में एक फ़िल्टरिंग अभिव्यक्ति लिख सकते हैं, हम उपयोगकर्ता कार्यों के आधार पर ग्रिड को फ़िल्टर कर सकते हैं।

उदाहरण के लिए, अप्रासंगिक अनुप्रयोगों की दृश्यता को सीमित करने के लिए, कोड से निम्नलिखित फ़िल्टरिंग अभिव्यक्ति का उपयोग प्रबंधक के लिए किया जाता है:

 public static Expression<Func<TOffer, bool>> FilterOffers<TOffer>() where TOffer : RentOfferBase { return a => a.Creator.SysName == SecurityHelper.CurrentLogin || a.Status.Name == ""; }

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

हम दूसरे के आधार पर एक फॉर्म फ़ील्ड को फ़िल्टर करना भी निर्धारित कर सकते हैं

 [FilterFor(typeof(RentOfferBase), "Metro")] public static Expression<Func<MetroStation, bool>> MetroFilter([Source("Line")]MetroLine line) { return a => line == null || a.MetroLine == line; }

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

व्यवस्था परिवर्तन करना

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

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

हमें CodeFirst में क्या मिलता है:

तेज़ इकाई विकास - हम लिखते हैं .net वर्ग शायद ही कभी डेटाबेस के बारे में सोचता है
संस्करण नियंत्रण प्रणाली में डेटाबेस को स्टोर करने का एक सुविधाजनक तरीका - हम केवल क्लास कोड को स्टोर करते हैं
संकलन समय पर व्यापार तर्क की मान्यता

लेकिन अपडेट के बारे में क्या?

प्रवास

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

एक नया क्षेत्र बनाएँ
एक नई इकाई बनाना
बढ़ी हुई सटीकता / क्षेत्र की लंबाई

बेशक, गंभीर अनुप्रयोगों को विकसित करते समय ये क्रियाएं पर्याप्त नहीं हैं, फ़ील्ड / इकाई का नाम बदलने पर क्या किया जाना चाहिए?

नाम बदलने वाले रीफैक्टरिंग लागू करें (हम ReSharper का उपयोग करते हैं)। इसके अलावा, हमारे कोड में इस क्षेत्र के सभी उपयोगों का नाम बदला गया है।
जिसमें फिल्टर्स, फॉर्म इवेंट्स, एंटिटी इवेंट्स में बदला हुआ नाम शामिल है। पाठ के रूप में होने वाली विशेषताओं में केवल फ़ील्ड नाम जटिलता का कारण बन सकते हैं, लेकिन यदि फ़ील्ड नाम पर्याप्त अद्वितीय है, तो कोई समस्या नहीं होगी। इस मामले में, नाम बदलने के बाद, आप संकलन शुरू कर सकते हैं और सुनिश्चित कर सकते हैं कि विशेषताओं में फ़ील्ड का सही नाम बदला गया है।
संकेत नाम जोड़ें। संकेत - ORM के लिए एक संकेत डेटाबेस के साथ क्या करना है अगर वर्ग-निर्मित स्कीमा और वास्तविक SQL स्कीमा के बीच अंतर हैं। फ़ील्ड का नाम बदलने का संकेत कुछ इस तरह है:
```
 public class RenameFieldUpgrader : ModelUpgraderBase { public override Version Version { get { return new Version("3.5.0.8764"); } } public override void AddUpgradeHints(ISet<UpgradeHint> hints) { hints.Add(new RenameFieldHint(typeof(RentOfferBase), "OldName", "NewName")); } } 
```

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

परिणाम

ORM का उपयोग करने के परिणामस्वरूप, हमने प्राप्त किया:

डेटा मॉडल और व्यावसायिक तर्क दोनों का सुविधाजनक और तेज़ विकास
सुविधाजनक, सरल और विश्वसनीय आवेदन समर्थन
सभी चरणों में OOP का लाभ उठाएं
कोड का पुन: उपयोग (कॉपी-पेस्ट को छोड़कर)
संकलन समय पर कोड सत्यापन
संक्षिप्त, स्पष्ट व्यावसायिक तर्क कोड

उद्यम अनुप्रयोग विकास में ओआरएम का उपयोग करना