दूसरे पर एक का उपयोग करने के क्या फायदे हैं? मुझे पता है कि पीओसीओ कक्षाएं अधिक इष्टतम हैं, लेकिन क्या वे ओवरकिल के लायक हैं? और क्या हमें हमेशा पीओसीओ का उपयोग करना चाहिए या क्या ऐसा समय है जब आपको इकाई ढांचे वर्गों को प्राथमिकता दी जानी चाहिए?पीओसीओ बनाम इकाई फ्रेमवर्क जेनरेटेड क्लासेस?
ईएफ डिफ़ॉल्ट कक्षाएं सभी ईएफ बेस क्लास से प्राप्त होती हैं, जबकि पीओसीओ (इसलिए नाम) नहीं है। ईएफ बेस क्लास से विरासत में रहते हुए, परिवर्तन ट्रैकिंग के पीछे तर्क आपके से छिपा हुआ है और सभी तर्क उस संदर्भ के अंदर संग्रहीत हैं जो आपके ऑब्जेक्ट्स के संदर्भ रखता है। यह वरीयता दी जाती है यदि आप एक जुड़े राज्य में काम कर रहे हैं, यानी, आपके पास एक ही समय में संदर्भ है जिसमें आपके पास संस्थाएं हैं। यह आमतौर पर वह मामला है जहां आप 'वसा' ग्राहक बनाते हैं, इसलिए ग्राहक और डेटाबेस केवल दो स्तर हैं।
दूसरी तरफ, यदि आप वेब सेवाओं/वेब फॉर्मों के साथ काम कर रहे हैं, तो आपके द्वारा पास की जाने वाली संस्थाओं के पास कोई संदर्भ नहीं है और उन्हें राज्य को ट्रैक करना होगा - फिर पीओसीओ बेहतर विकल्प है, क्योंकि वे ट्रैकिंग ऑब्जेक्ट को अपनी संपत्ति के रूप में बदल दिया है जिसे तब तक स्थानांतरित किया जा सकता है जब तक कि आप संदर्भ में परिवर्तन लागू करने और सहेजने का निर्णय नहीं ले लेते। एक अन्य लाभ यह होगा कि आपके ग्राहकों को .NET होने की आवश्यकता नहीं है और आपके ऑब्जेक्ट को deserialize करने के लिए EF .dll नहीं होना चाहिए।
कारण मैं पीओसीओ का उपयोग चिंताओं को अलग करता हूं यानी मैं नहीं चाहता कि मेरा फ्रंट एंड यह जान ले कि मेरा बैक एंड कैसे काम करता है। इसलिए यदि मैं लिंक से एसक्यूएल से ईएफ या एन हाइबरनेट में बदलना चाहता हूं तो मुझे अपने फ्रंट एंड कोड को संशोधित करने की आवश्यकता नहीं है।
यदि आप स्वच्छ वास्तुकला, ढीले युग्मन और सर्वोच्च टेस्टेबिलिटी चाहते हैं तो पीओसीओ का उपयोग करें।
यदि आपको उन चीजों की परवाह नहीं है तो उनका उपयोग न करें।
व्यक्तिगत रूप से मेरे लिए यह किसी भी आवेदन में सबसे महत्वपूर्ण चीजें हैं (विशेष रूप से एक जिसे लंबे समय तक बनाए रखने की आवश्यकता होती है), इसलिए मैं हमेशा पीओसीओ का उपयोग करता हूं।
इस बात को ध्यान में रखते हुए, पीओसीओ के लिए आपको कुछ प्रकार की परिवर्तन ट्रैकिंग तंत्र लागू करने की आवश्यकता है, जो मुश्किल हो सकता है। लेकिन यह एक बार सेटअप चीज है, और प्रयास के लायक है।
मेरे पास यह तर्क एक कस्टम डीएलएल में है जो मैं परियोजनाओं के बीच साझा करता हूं - इसलिए मुझे इसे बार-बार करने की ज़रूरत नहीं है।
सामान्य ज्ञान (ईएफ/.NET विशिष्ट नहीं) में पीओसीओ महत्वपूर्ण क्यों हैं, इसके लिए अधिक जानकारी के लिए, मेरा उत्तर here देखें।
निम्न लेख में देखो:
क्यों नहीं बस एक अंतरफलक है कि आपके एफई उत्पन्न वर्गों को लागू कर सकते के साथ अपने "POCO" प्रतिनिधित्व करते हैं? फिर आपकी यूआई (या ऊपरी स्तर की सेवा) केवल इंटरफ़ेस परिभाषाओं को काम करके ढीला युग्मन और परीक्षण योग्यता प्राप्त कर सकती है ... और रूपांतरण कार्यों को लिखने/निष्पादित करने की आवश्यकता नहीं होगी। – Reddog
@ रेडोग - ठीक है मेरी पीओसीओ असेंबली में 'System.Data.Entity'' का कोई संदर्भ नहीं है, ईएफ पर कोई निर्भरता नहीं है। यदि आप ईएफ जेनरेटेड क्लासेस का उपयोग करते हैं तो आपकी कक्षा लाइब्रेरी ईएफ को "बंधी" हो जाती है। अगर मैं किसी अन्य ओआरएम (या डीएएल) में जाना चाहता हूं, तो मैं अपने पीओसीओ कक्षाओं का पुनः उपयोग कर सकता हूं। ईएफ जेनरेटेड कक्षाओं के साथ भी ऐसा नहीं कहा जा सकता है। यह * अन्य * परियोजनाओं से ढीले युग्मन के बारे में नहीं है, यह पीओसीओ और एंटिटी फ्रेमवर्क के बीच ढीले युग्मन के बारे में है। यह एक सच्चे "डोमेन मॉडल" की अनुमति देता है। – RPM1984