क्या डोमेन ऑब्जेक्ट्स से Grails सेवाओं को कॉल करने के लिए यह खराब डिज़ाइन है?

Question

जैसा कि मैं अधिक से अधिक Grails का उपयोग कर रहा हूं, मैं खुद को कई नियंत्रकों में कोड लिख रहा हूं जो वास्तव में ऐसा लगता है कि यह एक डोमेन वर्ग का हिस्सा होना चाहिए। कभी-कभी, इस डोमेन कोड में सेवा कक्षा में कॉल होता है। उदाहरण के लिए, मैं हाल ही में एक डोमेन विधि है कि कुछ इस तरह देखा लिखा है:

class Purchase { 

    // Injected 
    def paymentService 

    String captureTransactionId 
    Boolean captured 

    // ... 

    def capture() { 
     captureTransactionId = paymentService.capturePurchase(this) 
     captured = captureTransactionId != null 
    } 

मैं एकमुश्त गंदा लेखन इस कोड को नहीं लग रहा है, लेकिन मैं Grails में सबसे अच्छा डिजाइन प्रथाओं का एक अध्ययन नहीं किया है, इसलिए मैं कुछ राय प्राप्त करना चाहता था।

Answer 1

मैं इस तरह की चीजों के साथ आगे और आगे जाता हूं। Grails से पहले मुझे एनीमिक डोमेन कक्षाओं में कोई समस्या नहीं थी और सब कुछ मददगारों में डाल दिया। एनीमिक कक्षाओं के साथ अक्सर समाप्त होने का बड़ा कारण सत्यापन है। वर्ग के अंदर शून्यता, लंबाई, आदि को मान्य करना सरल है लेकिन विशिष्टता के लिए डेटाबेस जांच की आवश्यकता होती है और यह किसी डोमेन क्लास (गैर-Grails ऐप में) के लिए प्रासंगिक नहीं है, इसलिए मैं इसे एक सहायक के पास ले जाऊंगा। अब मुझे दो स्थानों पर सत्यापन मिला है, इसलिए मैं सहायक में समेकित हो जाऊंगा और डेटा-केवल कक्षा के साथ छोड़ा जाएगा।

लेकिन Grails डोमेन कक्षाओं में GORM विधियों में तारों द्वारा डीएओ की आवश्यकता को प्रतिस्थापित करता है, और डोमेन कक्षाओं में सत्यापन डालकर वैधकर्ताओं की आवश्यकता को भी प्रतिस्थापित करता है। इसलिए यह तय करते समय समस्याएं उत्पन्न होती हैं कि डोमेन क्लास में किस व्यवसाय तर्क को जाना चाहिए और किसी सेवा या अन्य सहायक सेवाओं में क्या होना चाहिए - सेवाओं को व्यावसायिक तर्क डालने के लिए एक उत्कृष्ट जगह बनाती है जिसे डोमेन क्लास विधि या सत्यापनकर्ता में आवश्यक हो सकता है।

हां यह ओओ-शुद्ध नहीं है, हाँ आप एक चक्र बनाते हैं (सेवा डोमेन क्लास और डोमेन क्लास सेवा को कॉल करती है), नहीं, यह "वसंत रास्ता" नहीं है लेकिन बहुत सारे Grails "वसंत नहीं है मार्ग"।

इस तरह के युग्मन से ऐप को घटकों के लिए घटकों या प्लगइन में अलग करना मुश्किल हो जाता है, लेकिन 'def भुगतान सेवा' के साथ सेवाओं की घोषणा करना बहुत मदद करता है क्योंकि आप पैकेज नाम या कार्यान्वयन के साथ नहीं हैं।

Answer 2

मुझे नहीं लगता कि डोमेन/मॉडल कक्षाओं को कॉलिंग सेवाएं होनी चाहिए। यह दूसरा रास्ता 'दौर होना चाहिए।

एक सेवा उपयोग के मामले को पूरा करने के लिए अन्य सेवाओं को व्यवस्थित कर सकती है। मुझे लगता है कि जाने का सही तरीका है।

Answer 3

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

इसके अलावा यह "someService.someUsefulMethod (myDomainInstance)" से कुछ "myDomainInstance.someUsefulMethod()" के साथ कोड को और अधिक पठनीय बनाता है (उम्मीद है कि आप जानते हैं कि मेरा क्या मतलब है)।

Answer 4

मुझे यकीन नहीं है कि यह सही है या गलत है।

उदाहरण जैसे मामलों में, एक तरफ या दूसरे के बारे में क्या: या तो खरीद वर्ग के अंदर भुगतान सेवा.capturePurchase() कोड डालना, या आप सेवा में सभी तर्क डाल सकते हैं?