क्लीन आर्किटेक्चर - बहुत सारे केस क्लास का उपयोग करें


15

मैं क्लीन आर्किटेक्चर में जा रहा हूं और अपने एंड्रॉइड लेवल को MVC से MVP तक उठा रहा हूं , DI को डैगर 2, RxJava 2 के साथ रिएक्टिविटी और निश्चित रूप से Java 8 के साथ पेश कर रहा हूं।

में एमवीपी साफ वास्तुकला एक है संस्थाओं के बीच परत (डेटा संग्रहों में) और प्रस्तुतकर्ताओं कि उन तक पहुँचने चाहिए। यह परत "उपयोग केस" है । एक उपयोग मामला यह आदर्श रूप से एक इंटरफ़ेस है, जो एक इकाई पर एक ऑपरेशन को लागू करता है।

मुझे यह भी पता है कि क्लियर आर्किटेक्चर " चिल्ला रहा है ", इसकी परियोजनाओं के संदर्भ में वास्तव में उच्च पठनीय हैं क्योंकि उनमें उच्च संख्या में कक्षाएं हैं।

अब, मेरी परियोजना में, मेरे पास 6 अलग-अलग संस्थाओं की तरह कुछ है , और निश्चित रूप से, प्रत्येक संस्था के भंडार में कम से कम 4 विधियां हैं (आमतौर पर उन्हें प्राप्त करने के लिए, जोड़ें, हटाएं, अपडेट करें) .. इसलिए, 6 * 4 = 24

अगर मुझे क्लीन आर्किटेक्चर के बारे में अब तक समझ में आया है, तो मेरे पास 24 यूसेज कैस होंगे।

MVC में सिर्फ 6 नियंत्रकों की तुलना में यह बहुत सारी कक्षाएं हैं

क्या मुझे वास्तव में 24 उपयोग के मामले बनाने हैं?

मैं वास्तव में किसी के द्वारा स्पष्टीकरण की सराहना करूंगा जो पहले से ही इसका उपयोग सफलता के साथ कर रहा है।

धन्यवाद, जैक


1
क्या आप किसी ऐसे पृष्ठ का लिंक पोस्ट कर सकते हैं जो उदाहरण कोड के साथ इन उपयोग मामलों का विस्तार से वर्णन करता है?
रॉबर्ट हार्वे

मैंने बहुत कुछ जाना है, लेकिन मुख्य रूप से: यह ऐप नमूना और संबंधित लेख: github.com/jshvarts/Offline.ampleApp ; यह लेख: proandroiddev.com/… ; proandroiddev.com/… ; यह बात: youtube.com/watch?v=TvsOsgd0--c&feature=youtu.be ; और यह लेख भी: adityaladwa.wordpress.com/2016/10/25/…
जैकी देगल'नौसुनी

1
आपके द्वारा उद्धृत नमूना एप्लिकेशन या लेखों में से कोई भी क्लीन आर्किटेक्चर के साथ बहुत कुछ नहीं करता है। हालांकि, वे प्रतिक्रियाशील प्रोग्रामिंग के
रॉबर्ट हार्वे

सैंपल ऐप निश्चित रूप से क्लीन आर्किटेक्चर प्रतिमान के साथ बनाया गया है। अन्य लेख ज्यादातर .. क्या आप @RobertHadvey देखना चाहते हैं?
जैकी डेगल'इनुस्थानी

मेरा जवाब नीचे पढ़ें और जवाब दें।
रॉबर्ट हार्वे

जवाबों:


24

क्या मुझे वास्तव में 24 उपयोग के मामले बनाने हैं?

यदि आप जो कुछ भी लिखते हैं वह केवल CRUD है

नीचे दिए गए चित्र को देखें:

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

आपका दावा है कि आपके पास प्रत्येक इकाई के लिए छह अलग-अलग इकाइयाँ और 4 विधियाँ होंगी (बनाएँ, पढ़ें, अद्यतन और हटाएं)। लेकिन यह केवल आरेख (Entities परत) के बीच में पीले सर्कल में सच है। यूसेज केस लेयर में 24 विधियाँ बनाना व्यर्थ है जो केवल CRUD कॉल से एंटिटी लेयर तक जाती हैं।

एक उपयोग मामला "ग्राहक रिकॉर्ड जोड़ें" नहीं है। एक उपयोग मामला "ग्राहक को एक आइटम बेचें" (जिसमें ग्राहक, उत्पाद, और इन्वेंटरी इकाइयां शामिल हैं) या "इनवॉइस प्रिंट करें" (जिसमें समान इकाइयां शामिल हैं, चालान हैडर और इनवॉइस लाइन आइटम के अलावा ) की तर्ज पर अधिक है। )।

जब आप उपयोग मामले बनाते हैं, तो आपको व्यापार लेनदेन के बारे में सोचना चाहिए , न कि सीआरयूडी के तरीकों के बारे में।

इसके अलावा रीडिंग
एग्रीगेट - डोमेन ऑब्जेक्ट्स का एक क्लस्टर जिसे एक इकाई के रूप में माना जा सकता है


2
आप पैटर्न, प्रथाओं और वास्तुकला के बारे में सोचने में बहुत समय बिता रहे हैं, और बुनियादी सॉफ्टवेयर डिजाइन के बारे में सोचने के लिए पर्याप्त समय नहीं है। आप सभी के लिए ऐसी विधियाँ हैं जो व्यवसाय प्रथाओं को मूर्त रूप देती हैं, जैसा कि मैंने अपने उत्तर में बताया है।
रॉबर्ट हार्वे

1
यह आर्किटेक्चर चुनने का सवाल नहीं है। मेरी व्यक्तिगत राय: नंगे CRUD संचालन को सीधे इकाई परत से बात करनी चाहिए। बेशक, यह शायद क्लीन आर्किटेक्चर का उल्लंघन करता है।
रॉबर्ट हार्वे

1
आप थोड़े चूक रहे हैं। आर्किटेक्चर कोड को व्यवस्थित करने का एक साधन है। आप कोड लिखकर समस्याओं को हल करते हैं , न कि आर्किटेक्चर के साथ कुश्ती।
रॉबर्ट हार्वे

1
हे रॉबर्ट, यह इतना अच्छा नहीं है कि आप यह मान लें कि मैं कोड नहीं लिखता। मेरे उत्तर का विषय यह वास्तुकला पर है, और हम एसओ पर नहीं हैं। निष्ठापूर्वक मुझे आपकी अंतिम टिप्पणियाँ वास्तव में भ्रामक और बहरी लगती हैं। प्रश्न क्लीन आर्क में यूटेसकेस के बारे में है, कोड नहीं लिख रहा है। यदि आप कुछ संवाद करने की कोशिश कर रहे हैं तो कृपया बेहतर तरीके से समझाएं, क्योंकि मुझे आपकी टिप्पणियों की बात याद आ रही है। IMHO सॉफ्टवेयर विकसित करते समय आर्किटेक्चर के विचार से बचना संभव नहीं है, या कम से कम, अच्छे देवता सिर्फ कोड का गुच्छा नहीं लिखते हैं। इसके अलावा मैंने अपनी टिप्पणी में वास्तव में विशिष्ट प्रश्न पूछा, क्या आप जवाब दे सकते हैं? धन्यवाद
जैकी Degl'Innocenti

2
समस्या का समाधान जो आपने पहले किया था (ऐप ऑफलाइन पहले) वास्तव में क्लीन आर्किटेक्चर के साथ बहुत कुछ नहीं करना है। आपको क्लीन आर्किटेक्चर आरेख में उस समस्या का हल नहीं मिलेगा।
रॉबर्ट हार्वे

2

आप सही हैं अगर हर CRUD-Operation का एक UseCase में अनुवाद किया जाए। लेकिन एक UseCase में कई CRUD-Operation भी हो सकते हैं।

एक UseCase एक अलग मॉडल है जो विभिन्न डेटा स्रोतों से जानकारी इकट्ठा करता है और डेटा सिंक के लिए संचार तैयार करता है। इसमें कई CRUD- ऑपरेशंस शामिल हो सकते हैं।

इसलिए एक UseCase के बारे में सोचें, जहां ग्राहक के लिए चालान बनाना और ग्राहक को स्वयं बनाना क्योंकि वह सिस्टम में मौजूद नहीं है। आपके पास एक UseCase है जिसके परिणामस्वरूप एक लेनदेन में कम से कम दो क्रिएट-ऑपरेशन होते हैं।


तो कई संस्थाओं के साथ CRUD के उदाहरण के लिए आप किस पैटर्न को अपनाएंगे?
जैकी डेगल'नौसुनी

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

ठीक है, इसलिए, एक ऐसे केस का उपयोग करना जो विभिन्न विभिन्न कार्यों का प्रबंधन करता है, SRP का उल्लंघन नहीं करता है क्योंकि ऐसा लगता है कि एक ही UseCase में सिर्फ अलग-अलग तरीकों (और प्रवाह) को "एग्रीगेट" किया जाता है, इसके बिना कोई एकल प्रवाह एक से अधिक रेस्पॉन्सिबिलिटी को संभालता है। .. लेकिन इस तरह से हम सिर्फ एक UseCase के स्थान पर एक नियंत्रक नहीं बना रहे हैं? .. विचार .. हो सकता है कि उपयोग के मामले को बस एक परत के रूप में देखा जाना चाहिए, और उस परत को सिर्फ एसआरपी का सम्मान करना होगा, लेकिन कई तरीकों को भी लागू कर सकता है। मैं इस बारे में एक स्रोत या लेख
रखना चाहूंगा

1
एक यूसेकस एक नियंत्रक है। अंतर केवल इतना है, कि व्यापार के दृष्टिकोण से एक usecase आता है और एक नियंत्रक उस पर तकनीकी दृष्टिकोण है। एक usecase का ध्यान केंद्रित है, जो व्यापार मूल्य पैदा कर रहा है। तो एक usecase एक व्यापार मूल्य संचालित नियंत्रक कार्यान्वयन है।
oopexpert

1
सहमत हूं, एक HTTP नियंत्रक I / O को प्रबंधित करने का एक तरीका है, इसमें कंसोल कमांड, इवेंट रिएक्शन आदि भी हो सकते हैं। ये सभी I / O चैनल एक ही usecase कहते हैं। एक usecase व्यवसाय तर्क के लिए एक नियंत्रक है, यह I / O चैनलों के बारे में नहीं जानता है जिसे यह कहा जाता था, लेकिन यह जानता है कि नौकरी करने के लिए डोमेन संस्थाओं को कैसे ऑर्केस्ट्रेट किया जाए।
दिमित्रि लेझनेव

1

यूज़ केस की आपकी परिभाषा गलत है, यूज़ केस एक व्यावसायिक नियम को लागू करने वाला वर्ग है, इसे सीआरयूडी ऑपरेशन करने की आवश्यकता नहीं है, यह एक जटिल मल्टी स्टेप ऑपरेशन हो सकता है


आपकी सजा का मतलब यह नहीं है कि जब आपको वास्तव में विस्तृत श्रेणी के क्रूड जैसे ऑपरेशन को लागू करने की आवश्यकता हो, तो यहां तक ​​कि आपके विचार में इस तथ्य से कुछ संबंध हो सकते हैं कि एक उपयोग केस को एक पैटर्न का निरीक्षण करना चाहिए जिसमें हम एक जटिल ऑपरेशन तक पहुंच सकते हैं, यहां तक ​​कि बहु कदम।
जैकी डेगल'नौसन्ती
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.