डोमेन ऑब्जेक्ट्स, POCOs और संस्थाओं के बीच अंतर क्या है?


83

मैं इस धारणा के तहत था कि वे मूल रूप से एक ही हैं। क्या मॉडल ऑब्जेक्ट भी समान हैं?

अभी, मेरी वास्तुकला में, मेरे पास है:

class Person 
{

    public string PersonId;        
    public string Name;
    public string Email;

    public static bool IsValidName() { /* logic here */ }
    public static bool IsValidEmail() { /* logic here */ }
}


class PersonService
{
    private PersonRepository pRepository;

    PersonService()
    {
        pRepository = new PersonRepository();
    }

    public bool IsExistingEmail(string email)
    {
        //calls repo method to see if email is in db
    }


    public Person GetPerson(email)
    {
        return pRepository.Get(email);
    }


    public void SavePerson(Person p)
    {
        if (Person.IsValidEmail(p.Email) && !IsExistingEmail(p.Email)
        {
            pRepository.Save(p);
        }
    }

}


class PersonRepository
{
    public void Save(Person p)
    {
        //save to db
    }

    public Person Get(string email)
    {
        //get from db
    }

    public bool IsExistingEmail(string email)
    {
        //see if email in db
    }

}

ऊपर वर्गों में से जो तो कर रहे हैं POCO, Domain Object, Model object, entity?

जवाबों:


117

मेरी (अमानक) आम आदमी की परिभाषाएँ

  • POCO- सादा पुराना% Insert_Your_Language% ऑब्जेक्ट। एक प्रकार जिसमें कोई तर्क नहीं है। यह सिर्फ मेमोरी में डेटा स्टोर करता है। आप आमतौर पर इसमें सिर्फ ऑटो प्रॉपर्टी देखेंगे, कभी-कभी फील्ड और कंस्ट्रक्टर।
  • Domain objectएक वर्ग का एक उदाहरण जो आपके डोमेन से संबंधित है। मैं संभवतः किसी भी उपग्रह या उपयोगिता की वस्तुओं को डोमेन ऑब्जेक्ट से बाहर कर दूंगा, उदाहरण के लिए, ज्यादातर मामलों में, डोमेन ऑब्जेक्ट में लॉगिंग, फ़ॉर्मेटिंग, क्रमांकन, एन्क्रिप्शन आदि जैसी चीज़ें शामिल नहीं हैं - जब तक कि आप विशेष रूप से क्रमशः लॉग, सीरियल, फ़ॉर्मेट या एन्क्रिप्ट करने के लिए कोई उत्पाद नहीं बना रहे हैं। ।
  • Model objectमुझे लगता है कि जैसा है वैसा ही है Domain object। लोग इस विनिमय का उपयोग करते हैं (मैं गलत हो सकता है)
  • Entity एक वर्ग id
  • Repositoryएक वर्ग जो एक तरफ से डेटा भंडारण (जैसे एक डेटाबेस, एक डेटा सेवा या ओआरएम) और सेवा, यूआई, व्यावसायिक परत या किसी अन्य अनुरोध करने वाले निकाय से बात करता है। यह आमतौर पर सभी डेटा-संबंधित सामान (जैसे प्रतिकृति, कनेक्शन पूलिंग, मुख्य बाधाएं, लेनदेन आदि) को छुपाता है और डेटा के साथ काम करना आसान बनाता है
  • Serviceसॉफ्टवेयर है कि आम तौर पर सार्वजनिक एपीआई के माध्यम से कुछ कार्यक्षमता प्रदान करता है। परत के आधार पर, यह एक उदाहरण के लिए एक स्व-निहित कंटेनर, या वर्ग हो सकता है जो आपको आवश्यक प्रकार का एक विशेष उदाहरण खोजने की अनुमति देता है।

मूल उत्तर

ये ऐसे शब्द हैं जो बड़े पैमाने पर (वितरित) डोमेन ड्रिवेन डिज़ाइन में उपयोग किए जाते हैं। वे एक जैसे नहीं हैं। अवधि मॉडल वस्तु के लिए एक पर्याय के रूप में इस्तेमाल किया जा सकता डोमेन वस्तु

डोमेन ऑब्जेक्ट। व्यवसाय विशिष्ट क्षेत्र से ऑब्जेक्ट जो डोमेन विशेषज्ञ के लिए सार्थक कुछ का प्रतिनिधित्व करते हैं। डोमेन ऑब्जेक्ट ज्यादातर संस्थाओं और मूल्य वस्तुओं द्वारा दर्शाए जाते हैं। सामान्य बोल, डोमेन लेयर में रहने वाली अधिकांश वस्तुएँ मॉडल में योगदान करती हैं और डोमेन ऑब्जेक्ट होती हैं।

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

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

class Person- एंटिटी और POCO, इस वर्ग का उदाहरण डोमेन ऑब्जेक्ट
class PersonService- सर्विस
class PersonRepository- रिपोजिटरी है


4
कृपया ऊपर मेरा कोड नमूना देखें और मुझे बताएं कि आप शर्तें कैसे लागू करेंगे।
२०

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

1
यदि किसी POCO को पहचानने की आवश्यकता नहीं है, तो उसे ORM द्वारा कैसे लोड किया जा सकता है। यह तर्कसंगत नहीं है!
पास्कल

1
यह स्पष्ट रूप से गलत जानकारी क्यों सबसे उत्कीर्ण और स्वीकृत है। POJO एक प्रकार नहीं है जिसमें कोई तर्क नहीं है। वास्तव में, मार्टिन फाउलर ने विशेष रूप से एंटिटी बीन्स के खिलाफ विपरीत करने के लिए POJO शब्द गढ़ा था ("हम एंटिटी बीन्स का उपयोग करने के बजाय नियमित जावा वस्तुओं में व्यापार तर्क को एन्कोडिंग के कई लाभों की ओर इशारा कर रहे थे।")। martinfowler.com/bliki/POJO.html
इस उपयोगकर्ता की मदद

1
मैं माफी चाहता हूँ अगर मेरी टिप्पणी जोरदार शब्दों में किया गया था, लेकिन फिर से, अपने व्यक्तिगत अनुभव वास्तव में बात जब नहीं जाली सिक्के बनाने वाला अवधि के POJO परिभाषित स्पष्ट रूप से व्यापार तर्क को रोकने के लिए। वास्तव में, वह आपके अभ्यास को एनीमिक डोमेन मॉडल ( martinfowler.com/bliki/AnemicDomainModel.html ) के तहत वर्गीकृत करेगा, जिसे वह एक विरोधी पैटर्न मानता है, और वह अनुशंसा करता है कि आप इसके बजाय POOO का उपयोग करें। यह चाहे एक विरोधी पैटर्न इस परिभाषा के दायरे से बाहर है, लेकिन एक बात स्पष्ट है: POJO करता नहीं किसी भी व्यवसाय के तर्क के बिना एक वस्तु मतलब है।
मदद की जरूरत है

19

मूल रूप से यह आंतरिक तर्क के लिए आता है

  1. डोमेन ऑब्जेक्ट्स में सत्यापन आदि जैसी चीजों के लिए आंतरिक डोमेन लॉजिक होता है।
  2. मॉडल मूल रूप से एक लाइट डोमेन ऑब्जेक्ट है, वे उस डेटा के बारे में जानते हैं जो वे रखते हैं लेकिन वास्तव में कुछ भी नहीं है कि यह कैसे उपयोग किया जा रहा है
  3. संस्थाएँ डेटा रखती हैं और कुछ आंतरिक ज्ञान रखती हैं कि यह कहाँ से आया है, और यह कहाँ सहेजा जा रहा है, अपडेट किया गया है, आदि
  4. POCO डेटा रखता है और इसे स्वयं के बारे में कुछ आंतरिक ज्ञान हो सकता है, चीजें जैसे कि एक संपत्ति संग्रह में सभी वस्तुओं का कुल मूल्य क्या है
  5. डीटीओ सभी का सबसे सरल आइटम है, यह सिर्फ डेटा रखता है और इसका कोई तर्क नहीं है

वे सभी मूल रूप से एक ही चीज के लिए उपयोग किए जाते हैं, यह सिर्फ यह है कि आप उन्हें कितना स्मार्ट चाहते हैं

आपके कोड नमूने के अनुसार व्यक्ति वर्ग एक डोमेन ऑब्जेक्ट या मॉडल होगा, अन्य 2 एक सेवा और एक रिपॉजिटरी हैं। डोमेन ऑब्जेक्ट, Pocos, मॉडल, dtos, आदि का उपयोग संदेशों की तरह किया जाता है, एक लेयर से दूसरी में पास किया जाता है, पर्सन सर्विस की तरह एक सर्विस क्लास, ApplicationRepository जैसी रिपॉजिटरी क्लास के साथ एप्लीकेशन में एक लेयर होती है। एक अच्छे ओवर व्यू के लिए http://bob-the-janitor.blogspot.com/2009/07/n-tier-design-revisit-part-1-over-view.html इस मामले में इसे उपयोग करने की बात कर रहे हैं एक डेटा इकाई जो मूल रूप से एक dto है


18

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

ऐसा नहीं है कि कोई कार्यात्मक अंतर है, वे किसी चीज़ का अधिक बारीकी से वर्णन करने के लिए अलग-अलग शब्द हैं। रेस कार, ट्रक और परिवार सेडान के बीच अंतर की तरह। सभी ऑटोमोबाइल हैं, लेकिन प्रत्येक शब्द अधिक वर्णनात्मक है।


मैंने एक कोड नमूना शामिल करने के लिए अद्यतन किया, क्या आप कृपया टिप्पणी कर सकते हैं? मैं केवल यह सुनिश्चित करना चाहता हूं कि जब मैं प्रश्न पूछ रहा हूं, तो मैं सही शब्दों का उपयोग कर रहा हूं।
jpshook

11

उपरोक्त उत्तरों में पहले से ही डोमेन और मॉडल की अच्छी व्याख्याएं हैं।

एक डेटाबेस-संदर्भ में इकाई का अर्थ है एक वस्तु संबंध मॉडल ईआरडी में आइटम । (यानी एक तालिका में एक पंक्ति)

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

पोकोस (प्लेन ओल्ड कॉमनरंटाइम ऑब्जेक्ट्स) पर्सिस्टेंसफ्रेमवर्क (एंटिटीफ्रेमवर्क या एनएचबर्नेट) के बिना मौजूद हो सकते हैं, इस प्रकार वे परीक्षण करने में बहुत आसान हैं।

पोको शब्द पोजो (प्लेन ओल्ड जावा ऑब्जेक्ट) का रूपांतर है जो उसी कारण से जावा दुनिया में बनाया गया था।


डाउनवॉटिंग का कारण क्या है? सवाल था "डोमेन ऑब्जेक्ट्स, POCO और संस्थाओं के बीच अंतर क्या है?" मैंने एंटिटी और पोको के बीच का अंतर समझाया
k3b

"उपरोक्त उत्तरों में पहले से ही डोमेन और मॉडल की अच्छी व्याख्याएँ हैं।" मैं एक उत्तर का चयन कैसे कर सकता हूं जो मान्य उत्तर के रूप में अन्य उत्तरों पर निर्भर करता है?
jpshook

एन.पी. पूर्वव्यापी में मुझे आपको केवल एक पूर्ण उत्तर प्रदान करने के लिए कहना चाहिए। अगली बार 2x सोचेंगे।
jpshook

3

एक डोमेन ऑब्जेक्ट आपके एप्लिकेशन की डोमेन परत में एक इकाई है, जैसे। एक पता वर्ग। "मॉडल" का मतलब एक ही है - "डोमेन मॉडल" में एक इकाई।

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


POCO एक इकाई नहीं हो सकता? मुझे लगा कि पीओसीओ में व्यवहार हो सकता है लेकिन दृढ़ता से अनभिज्ञ होना चाहिए?
jpshook

@Developr हाँ, आपके डोमेन मॉडल / इकाइयाँ वास्तव में POCO की हो सकती हैं - यह वही है जो एक "एनीमिक" डोमेन मॉडल के रूप में जाना जाता है - देखें martinfowler.com/bliki/AnemicDomainModel.html
मैटलैवी

आप इसे एनीमिक कैसे मानेंगे? आप "समृद्ध डोमेन ऑब्जेक्ट" कैसे परिभाषित करते हैं? यदि डोमेन ऑब्जेक्ट्स डेटाबेस के साथ प्रत्यक्ष या अप्रत्यक्ष रूप से बातचीत नहीं कर सकते हैं, तो उनके पास किस प्रकार की समृद्ध कार्यक्षमता हो सकती है?
jpshook

@Developr मैं POCO ऑब्जेक्ट एनेमिक से बना एक डोमेन मॉडल पर विचार करेगा क्योंकि परंपरागत रूप से POCO वर्गों के पास कोई समृद्ध कार्यक्षमता, बस डेटा नहीं है। सेपरेशन ऑफ़ कंसर्न्स सिद्धांत ( en.wikipedia.org/wiki/Separation_of_concerns ) का अनुसरण करते हुए, डोमेन मॉडल में एक ऑब्जेक्ट को डेटाबेस एक्सेस से बिल्कुल भी संबंधित नहीं होना चाहिए (इसलिए लोकप्रिय शब्द "दृढ़ता अज्ञानता")। डोमेन मॉडल में एक इकाई की कार्यक्षमता जिस तरह की होनी चाहिए, वह व्यावसायिक तर्क है - उन्हें उस समस्या / डोमेन के तार्किक नियमों और वर्कफ़्लोज़ को कैप्चर करना और इनकैप करना चाहिए जो वे प्रतिनिधित्व करते हैं।
मैटवेवी
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.