दिलचस्प पोस्ट
पिक्सल में फ़ॉन्ट आकार JTable नहीं दिखा रहा है हॉवर के साथ बूटस्ट्रैप ड्रॉपडाउन स्वयं हस्ताक्षरित वेबसाइट देखने के लिए UIWebView (कोई निजी एपीआई, NSURL कनेक्शन नहीं) – क्या यह संभव है? क्या यह संभव है कि जावा में कुछ समानता बनायी जा सकती है, लेकिन कस्टम बराबर () और हैशोड () को कार्यान्वित करने के लिए आवेदन तक प्रतीक्षा करें। गणना करें समाप्त हो गया है उच्च खोज गिनती के लिए vlookup को अनुकूलित कैसे करें? (VLOOKUP के विकल्प) क्या लॉक () गारंटी का अनुरोध किया गया है? Firebase onMessage पृष्ठभूमि में एप जब फोन नहीं कहा जाता है ट्विटर बूटस्ट्रैप 3 में उत्तरदायी विशेषताएं कैसे निकालें? PHP से जावास्क्रिप्ट में चर प्राप्त करें आर: स्व लिखित पैकेज में मैग्रिटर पाइप ऑपरेटर का उपयोग करें स्प्रिंग सुरक्षा और @ एसिंक जब सी # में स्ट्रिंग में दिखता है तो {0} क्या मतलब है? "मेमोरी से बाहर" एक पुनर्प्राप्ति योग्य त्रुटि है?

परिवर्तन के लिए इकाई वर्ग बंद कर रहा है

मेरे पास एक डेटाबेस संबंध है जैसा नीचे दिखाया गया है डोमेन ऑब्जेक्ट LINQ से SQL ORM पर आधारित बनाए गए हैं।

भुगतान में नकद भुगतान और उपहार कूपन भुगतान शामिल हैं। मान लीजिए कि खरीद की कुल राशि 550 है। इसे निम्नलिखित घटकों के रूप में भुगतान किया जा सकता है

1 Gift Coupon Valued 300 1 Gift Coupon Valued 200 I Cash Currency Valued 50 

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

मैं ORM के "InsertOnSubmit" फ़ंक्शन का उपयोग करके नए भुगतान रिकॉर्ड को सम्मिलित कर रहा हूं I निम्नलिखित कोड ठीक काम कर रहा है। हालांकि, अगर मैं कंपनी क्रेडिट कार्ड का उपयोग करके एक नया भुगतान घटक पेश कर रहा हूं, तो मुझे अपने "भुगतान" डोमेन वर्ग में बदलाव करने की आवश्यकता है I मैं ओआरएम का उपयोग करते हुए विस्तारण के लिए भुगतान वर्ग को कैसे खोल सकता हूं और परिवर्तन के लिए बंद कर सकता हूं?

नोट: भुगतान वर्ग के व्यवहार हैं (जैसे GetTotalAmountCollected) ओसीपी को संतुष्ट करने के लिए मैं "भुगतान" वर्ग बनाने की कोशिश कर रहा हूं।

नोट: कूपन प्रकार के लिए एक विशिष्ट व्यवहार है क्या कूपन जारी की गई तारीख 1/2/2000 से कम है, इसका उपयोग कुल राशि के लिए गणना में नहीं किया जाना चाहिए (यानी, कूपनवाले शून्य होना चाहिए)। रणनीति पैटर्न का उपयोग करके रिफैक्टरिंग कोड भी देखें

नोट: मैं .NET 4.0 का उपयोग कर रहा हूँ

संदर्भ:

  1. इकाई फ़्रेमवर्क के साथ ObjectContext.AddObject का उपयोग करते समय एक त्रुटि हो रही है
  2. रणनीति पैटर्न का उपयोग कर रिफैक्टरिंग कोड
  3. विरासत पर रचना को प्राथमिकता है?
  4. कोड-पहले बनाम मॉडल / डाटाबेस-पहले
  5. एकता का उपयोग करके रणनीति पैटर्न और निर्भरता इंजेक्शन
  6. सी # रणनीति डिलीवरी पैटर्न प्रतिनिधि द्वारा बनाम OOP
  7. सी # के साथ रणनीति पैटर्न का उपयोग कैसे करें?
  8. ईएफ कोड के साथ उत्तराधिकार पहले: भाग 2 – तालिका प्रति प्रकार (टीपीटी) http://weblogs.asp.net/manavi/archive/2010/12/28/inheritance-mapping-strategies-with-entity-framework-code-first -ctp5-भाग-2-तालिका-प्रति-प्रकार-tpt.aspx

सी # कोड:

 public class PaymentAppService { public RepositoryLayer.ILijosPaymentRepository Repository { get; set; } public void MakePayment() { DBML_Project.Payment paymentEntity = new DBML_Project.Payment(); paymentEntity.PaymentID = 1; paymentEntity.PaymentType = "PurchaseP"; DBML_Project.CashPayment cashObj = new DBML_Project.CashPayment(); cashObj.CashPaymentID = 1; cashObj.CurrencyNumber = 123; cashObj.CurrencyValue = 100; DBML_Project.GiftCouponPayment giftCouponObj = new DBML_Project.GiftCouponPayment(); giftCouponObj.GiftCouponPaymentID = 1; giftCouponObj.CouponValue = 200; giftCouponObj.CouponNumber = 124; paymentEntity.CashPayments = new System.Data.Linq.EntitySet<DBML_Project.CashPayment>(); paymentEntity.CashPayments.Add(cashObj); paymentEntity.GiftCouponPayments = new System.Data.Linq.EntitySet<DBML_Project.GiftCouponPayment>(); paymentEntity.GiftCouponPayments.Add(giftCouponObj); Repository.InsertEntity(paymentEntity); Repository.SubmitChanges(); } } 

भंडार:

 public class LijosPaymentRepository : ILijosPaymentRepository { public System.Data.Linq.DataContext MyDataContext { get; set; } public void InsertEntity(DBML_Project.Payment payment) { //Insert the entity MyDataContext.GetTable<DBML_Project.Payment>().InsertOnSubmit(payment); } public void SubmitChanges() { MyDataContext.SubmitChanges(); } } 

Solutions Collecting From Web of "परिवर्तन के लिए इकाई वर्ग बंद कर रहा है"

समस्या के लिए कि @ लिजो अमूर्त दृष्टिकोण को हल करने की कोशिश करता है बेहतर होगा

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

उदाहरण:

 public interface IPayment { int Id { get; set; } int PaymentId { get; set; } //Other payment specific properties or methods } public partial class CashPayment : IPayment { public int Id { get { return CashPaymentId ; } set { CashPaymentId = value; } } //Other properties } public partial class CreditCardPayment : IPayment { //more code ... } 

सभी भुगतान प्राप्त करने के लिए आपके ईएफ संदर्भ पर कुछ

 public partial class PaymentEntities //The name of your EF entities { public IQueryable AllPayments { return this.CashPayment.Union(this.CreditCardPayment); //This is not good, but just an example. The abstract class approach would be better here. } public void InsertPayment(IPayment payment) { this.AddObject(payment.GetType().Name, payment); } } 

संभवतः ओआरएम में विरासत का लाभ लेने के लिए एक वैकल्पिक विकल्प होगा। ताकि एन संग्रह होने के बजाय, भुगतान इकाई में प्रत्येक प्रकार के लिए एक। आपके पास एक ही संग्रह में सभी उपप्रकार होंगे। और जो सभी जोड़े गए हैं, वे पूरे भुगतान का प्रतिनिधित्व करेंगे।

हो सकता है कि चीजों को थोड़ा अलग ढंग से नाम देना आसान हो। उदाहरण के लिए, चलो एक खरीद की अवधारणा पर विचार करें। खरीद में भुगतान का संग्रह होना चाहिए। और भुगतान एक अमूर्त वर्ग हो सकता है, जिसमें से नकद , कूपन , क्रेडिट कार्ड , सभी वारिस

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

इस तरह, यदि कोई नया भुगतान प्रकार उठता है, तो आपका मॉडल एक ही रहेगा, आपके पास सिर्फ एक नया उपप्रकार होगा

अधिकांश ओआरएम आजकल विरासत के लिए अलग-अलग हठ योजनाओं का समर्थन करते हैं, जिससे आपके डेटा संरचना को भी साफ रखने में मदद मिलेगी।

प्रत्येक प्रकार के भुगतान के लिए एक नया प्रकार बनाने का जोड़ा मूल्य क्या है? मैं 'भुगतान द्वारा पैसे' के बीच का अंतर देख सकता हूं, और 'एक वाउचर के माध्यम से भुगतान किया' मैं उस विभेद को बनाने के लिए दो भिन्न प्रकारों के लिए सहमत हो सकता हूं।

हालांकि, CashPayment , एक CreditCardPayment आदि के बीच भेद क्यों बनाते हैं …? क्या आपको भुगतान के प्रकार के आधार पर अतिरिक्त जानकारी रखने की ज़रूरत है? क्या व्यवहार बदलता है?

आप इसे सरल क्यों न रखते हैं और नियमित Payment लिए एक अतिरिक्त संपत्ति जोड़ते हैं, जो एक भेदभावक के रूप में कार्य करता है और आपको जानकारी कैसे प्रदान करता है (क्रेडिट कार्ड, नकदी के माध्यम से …) देता है?

 public class Payment {} public class VoucherPayment : Payment {} public class MoneyPayment : Payment { public PaymentMode { get; set; } } public enum PaymentMode { Cash, CreditCard } 

आप मेज-प्रति-पदानुक्रम (http://msdn.microsoft.com/en-us/library/bb738443) का उपयोग करते हुए अपने मॉडल को परिभाषित कर सकते हैं जो एक भेदभावक (अर्थात, आपके मामले में भुगतान प्रकार) का उपयोग करता है, ताकि उसका विशेष स्वाद निर्दिष्ट किया जा सके आप जो भुगतान कर रहे हैं तो आप कॉलम जोड़ने के लिए आभारी होंगे यदि नए भुगतान के लिए अधिक डेटा की आवश्यकता होती है; हालांकि, ईएफ, आपके द्वारा संस्थाओं को कैसे परिभाषित करता है और उन संस्थाओं को आपके डेटा स्टोर में कैसे मैप करता है, के मामले में काफी लचीला है। संभवत: आपके पास कॉलम जैसे नंबर और वैल्यू का एक आम सेट हो सकता है और फिर सभी शेयरपॉईज पर जाएं और जेनेरिक नामों जैसे स्ट्रिंगवैल्यू 1 को डेटाबेस से जोड़ दें। फिर आप उन कॉलमों को अपने संकल्पनात्मक मॉडल में बेहतर नामांकित गुणों में नक्शा कर सकते हैं जो आपके डोमेन को और अधिक समझ में आ जाएगा।

यह मूल रूप से आपके डेटाबेस स्कीमा को एकल तालिका में समतल करता है, लेकिन आपका मॉडल अलग वर्गों में रहता है। आप या तो डेटा स्टोर या भुगतान वर्ग को प्रभावित किए बिना अतिरिक्त भुगतान प्रकारों के लिए अपने भुगतान वर्ग को उप-वर्ग कर सकते हैं; हालांकि, आपको नए भुगतान प्रकार जोड़ने के लिए मॉडल को संशोधित करने और उन्हें उपयुक्त कॉलम में मैप करने की आवश्यकता होगी।