दिलचस्प पोस्ट
कैसे आप ट्विटर बूटस्ट्रैप Accordion बना एक समूह खुला रखना? अनुक्रमणिका त्रुटि: सीमा से बाहर सूची असाइनमेंट सूची आच्छादित पृष्ठभूमि क्षेत्र की चमक के आधार पर पाठ रंग बदलें? स्प्रिंग बूट – एप्लिकेशन.आईएमएल से मानचित्र इंजेक्ट करें TextView.setTextSize असामान्य रूप से व्यवहार करता है – विभिन्न स्क्रीन के लिए गतिशील रूप से टेक्स्टएव का टेक्स्ट आकार सेट करना डाक एक फ़ील्ड को एक फार्म पर कैसे सेट करें? कर्म में चमेली परीक्षण: अनचाहे संदर्भ संदर्भ: आवश्यकता परिभाषित नहीं है कैसे कोर डेटा में संग्रहीत डेटा देखें? PHP में preg करने के लिए मैं ereg expressions कैसे बदल सकता हूँ? क्यों जेपीएसपैक्शन में जेस्क्रोलपैन अपनी सारी सामग्री नहीं दिखा रहा है? ExecJS :: उपयोगकर्ता में रनटाइम त्रुटि # इंडेक्स (आरओआर) क्या किसी प्राकृतिक भाषा से तिथियों और समय को पार्स करने के लिए कोई अजगर पुस्तकालय है? एक्सेन्ट और सभी वर्णों को कैसे हटाया जा सकता है <> a..z में sql-server? XmlDocument बनाम XmlReader का उपयोग कब करना चाहिए सीएसएस विशेषता चयनकर्ता में "i" क्या होता है?

ऑब्जेक्ट के अंदर सभी सहयोगी / समग्र वस्तुएं प्राप्त करें (सार रास्ते में)

व्यवसाय :

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

कक्षा :

मेरे पास एक भुगतान वर्ग है I इसमें गिफ़्टकॉन्प पेमेंट, क्लबमॉंब्सशिप कार्ड भुगतान, कैश पेमेंट आदि जैसे भुगतान के घटक हैं। प्रत्येक घटक प्रकार एक सामान्य इंटरफ़ेस IPaymentComponent को संतुष्ट करता है। मैंने मौजूदा प्रकारों के बारे में ज्ञान का उपयोग करके इसे कार्यान्वित किया है।

प्रशन

1) इस फ़ंक्शन को एक अमूर्त तरीके से कैसे कार्यान्वित करें – यह जानने के बिना कि सभी प्रकार मौजूद हैं? इसका मतलब है कि इसे IPaymentComponent इंटरफ़ेस को लागू करने वाले सभी प्रकार के लिए काम करना चाहिए।

2) यदि यह LINQ से SQL में प्राप्त करना संभव नहीं है, तो क्या यह इकाई फ़्रेमवर्क में संभव है?

3) क्या यह एसोसिएशन / एकत्रीकरण या संरचना है जब LINQ से एसक्यूएल भुगतान के अंदर गिफ्ट कूपन भुगतान संस्थाओं को उत्पन्न करता है?

नोट: मैं LINQ से SQL के रूप में ORM का उपयोग कर रहा हूँ। उपहार कूपन भुगतान और भुगतान ऑटोगेनेरेटेड क्लासेस हैं और इन ऑब्जेक्ट ORM द्वारा बनाए जाते हैं। मैंने आंशिक कक्षाओं का उपयोग करके इन वर्गों में अधिक कार्यक्षमता जोड़ दी है I

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

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

एक रिसाव अमूर्तता किसी भी लागू अमूर्तता को संदर्भित करता है, जिसका उद्देश्य जटिलता को कम करने (या छिपाना) है, जहां अंतर्निहित विवरण पूरी तरह से छिपा नहीं है

LINQ से SQL आरेख

यहां छवि विवरण दर्ज करें

संदर्भ :

  1. संस्था फ्रेमवर्क 4, विरासत में बनाम बनाते हुए?
  2. एक वंशानुक्रम रणनीति का चयन कैसे करें http://blogs.msdn.com/b/alexj/archive/2009/04/15/tip-12-choosing-an-inheritance-strategy.aspx
  3. फ्लुअन्ट एपीआई नमूनों – http://blogs.msdn.com/b/adonet/archive/2010/12/14/ef-feature-ctp5-fluent-api-samples.aspx

सी # CODE

public interface IPaymentComponent { int MyID { get; set; } int MyValue { get; set; } int GetEffectiveValue(); } public partial class GiftCouponPayment : IPaymentComponent { public int MyID { get { return this.GiftCouponPaymentID; } set { this.GiftCouponPaymentID = value; } } public int MyValue { get { return this.CouponValue; } set { this.CouponValue = value; } } public int GetEffectiveValue() { if (this.CouponNumber < 2000) { return 0; } return this.CouponValue; } } public partial class Payment { public List<IPaymentComponent> AllPaymentComponents() { List<IPaymentComponent> allPayComps = new List<IPaymentComponent>(); List<GiftCouponPayment> giftCouponPaymentList = new List<GiftCouponPayment>(); List<CashPayment> cashPaymentList = new List<CashPayment>(); foreach (GiftCouponPayment g in this.GiftCouponPayments) { giftCouponPaymentList.Add(g); allPayComps.Add(g); } foreach (CashPayment c in this.CashPayments) { cashPaymentList.Add(c); allPayComps.Add(c); } return allPayComps; } } 

Solutions Collecting From Web of "ऑब्जेक्ट के अंदर सभी सहयोगी / समग्र वस्तुएं प्राप्त करें (सार रास्ते में)"

मुझे लगता है कि आप एक पल के लिए डिजाइन से पीछे हटना चाह सकते हैं। मैंने जो सुना है वह यह है:

भुगतान में एक या एक से अधिक घटक होते हैं, और प्रत्येक घटक विभिन्न प्रकारों में से एक हो सकता है

आपकी ज़रूरत की तरह यह एक Payment तालिका है, फिर PaymentComponent तालिका पर किसी विदेशी कुंजी रिश्ते के साथ एक PaymentComponent तालिका। फिर आप अपने विभिन्न भुगतान प्रकारों के लिए PaymentComponent तालिका पर उत्तराधिकार लागू कर सकते हैं।

आप एक अमूर्त परत या एक डेटा ऐक्सेस परत का उपयोग करने की कोशिश कर सकते हैं जो सामान्य टी प्रकार के हो। या कम से कम तरीकों को सामान्य बनाने के लिए

आप मूल रूप से यहाँ कुछ मुद्दे हैं:

  1. भुगतान प्रकारों को कैसे मॉडल करें

    मान लीजिए हम इस पर क्लासिक OOP तरीके से जाना चाहते हैं:

    आपको एक बेस क्लास, पेमेंट (या पेमेंटबेज) की आवश्यकता है जो अमूर्त और विभिन्न वर्ग है जो इसे से भुगतान करता है जैसे भुगतान InCash, PaymentWithCreditCard और आदि।

    यदि आप ऐसा करने का विकल्प चुनते हैं, तो एक विकल्प भुगतान के लिए भुगतान विवरण जोड़ सकते हैं और भुगतान विवरण के पदानुक्रम का निर्माण कर सकते हैं, सभी निम्न बिंदुओं पर PaymentDetails के साथ भुगतान की जगह ले सकते हैं।

    कई विधियों के भुगतान के लिए , आप या तो:

    ए। एक भुगतान के तहत PaymentDetails का संग्रह है
    या
    ख। एकत्रित भुगतान नामक एक प्रकार का निर्माण करें जिसमें भुगतान की सूची है।

  2. तालिकाओं में भुगतान प्रकारों को कैसे मैप करें

    दोनों टीपीटी और टीपीएच वैध हैं …

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

    टीपीएच के लिए एक मेज पर एक भेदभाव करनेवाला स्तंभ (जैसे पेमेंट टाइप) के साथ एक तालिका का उपयोग करें, और प्रत्येक स्तंभ को चिह्नित करें जो कि पदानुक्रम में सभी इकाइयों के बीच नल योग्य नहीं है। विभिन्न संस्थाओं में विभिन्न गुणों के लिए समान कॉलम का उपयोग न करें। ईएफ में, प्रत्येक इकाई को एक ही तालिका में शर्त के साथ भुगतान करें भुगतान प्रकार = (संख्या यहां जाती है) और (स्तंभ का नाम (जो कि रिक्त नहीं होना चाहिए) नल नहीं है।

    मेरी सिफारिश है, यदि आपके पास कई संकीर्ण प्रकार (कुछ गुण हैं प्रत्येक) टीपीएच के साथ जाते हैं, अगर आपके पास कुछ व्यापक प्रकार टीपीटी के साथ होते हैं

  3. भुगतान एल्गोरिथम के लिए कौन सी डिजाइन पैटर्न / कोड तकनीक का उपयोग करना है

    आपके पास यहां अधिक विकल्प हैं:

    ए। आंशिक कक्षाओं का उपयोग करें और बेस क्लास पर अमूर्त प्रोसेस पेमेंट () विधि डालें और इनहेरिटिंग क्लासेस में ओवरराइड करें।

    ख। एक आधार भुगतानप्रोसेसर वर्ग और प्रति भुगतान प्रकार जैसे भुगतान InCashProcessor का उपयोग करें। इस पद्धति में आप सही भुगतानप्रक्रिया प्रकार लोड करने के लिए प्रतिबिंब का उपयोग कर सकते हैं या तो जेनिनाइक्स का इस्तेमाल करते हुए या तो अभी तक एक dictionay या बेहतर भंडारण कर सकते हैं:

 abstract class PaymentProcessor { } abstract class PaymentProcessor<TPayment> : PaymentProcessor where TPayment : class, Payment { } class PaymentInCashProcessor : PaymentProcessor<PaymentInCash> { } // Use reflection to find types that inherits from PaymentProcessor<PaymentInCash> // create an instance of the type you found // then cast the instance to PaymentProcessor<PaymentInCash> to use 

यदि आप अपने ईएफ मॉडल को डिज़ाइन करते हैं तो आप भुगतान नामक एक बेस क्लास पर अमूर्त संपत्ति का उपयोग कर सकते हैं। और आपके सभी भुगतान प्रकारों को उस वर्ग के वारिस दें:

इकाई फ़्रेमवर्क मॉडल

भुगतान में सभी सामान्य गुण हैं, और प्रत्येक विशिष्ट प्रकार की अपनी संपत्ति हो सकती है

यदि आपके पास इस प्रकार का मॉडल है तो आप भुगतान के लिए बस पूछ सकते हैं

यह सभी ऑब्जेक्ट्स देता है जो भुगतान प्रकार के वारिस हैं:

 var allPayments = objectContext.Payments;