सर्विस लेयर बनाना कितना आवश्यक है?

Question

मैंने 3 परतों (डीएएल, बीएल, यूआई) में एक ऐप बनाना शुरू किया [यह मुख्य रूप से सीआरएम, कुछ बिक्री रिपोर्ट और इन्वेंट्री को संभालता है]।

एक सहकर्मी ने मुझे बताया कि मुझे सर्विस लेयर पैटर्न में जाना चाहिए, ताकि डेवलपर्स अपने अनुभव से सर्विस पैटर्न में आए और इन एप्लिकेशन को डिजाइन करना बेहतर तरीका है। उन्होंने कहा कि भविष्य में इस तरह से एप्लिकेशन को बनाए रखना काफी आसान होगा।

व्यक्तिगत रूप से, मुझे लग रहा है कि यह सिर्फ चीजों को और अधिक जटिल बना रहा है और मैं इससे बहुत लाभ नहीं देख सकता जो इसे उचित ठहराएगा।

इस ऐप में एक अतिरिक्त छोटा आंशिक यूआई है जो डेस्कटॉप एप्लिकेशन कार्यों के कुछ (लेकिन केवल कुछ) का उपयोग करता है इसलिए मैंने खुद को कुछ कोड (लेकिन बहुत ज्यादा नहीं) की नकल करते हुए पाया। बस कुछ कोड दोहराव के कारण मैं इसे सेवा उन्मुख होने के लिए परिवर्तित नहीं करूंगा, लेकिन उन्होंने कहा कि मुझे इसे वैसे भी उपयोग करना चाहिए क्योंकि सामान्य तौर पर यह एक बहुत अच्छी वास्तुकला है, क्यों प्रोग्रामर सेवाओं के बारे में इतने भावुक हैं ??

मैंने उस पर Google करने की कोशिश की, लेकिन मैं अभी भी भ्रमित हूं और यह तय नहीं कर सकता कि क्या करना है।

Answer 1

मार्टिन फाउलर की पुस्तक "पैटर्न ऑफ़ एंटरप्राइज आर्किटेक्चर" में कहा गया है:

उत्तर देने के लिए आसान सवाल शायद तब है जब इसका उपयोग नहीं करना है। यदि आपके एप्लिकेशन के व्यावसायिक तर्क में केवल एक प्रकार का क्लाइंट होगा - उपयोगकर्ता इंटरफ़ेस - तो इसका उपयोग करने के लिए आपको किसी सर्विस लेयर की आवश्यकता नहीं है और यह ऐसी प्रतिक्रियाओं का उपयोग करता है जिसमें एकाधिक लेन-देन संसाधन शामिल नहीं होते हैं। [...]

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

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

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

Service Layer होने का एक और लाभ यह है कि इसे स्थानीय या दूरस्थ मंगलाचरण, या दोनों के लिए डिज़ाइन किया जा सकता है - और आपको ऐसा करने का लचीलापन देता है। पैटर्न एक अनुप्रयोग के व्यावसायिक तर्क के एनकैप्सुलेटेड कार्यान्वयन और विभिन्न ग्राहकों द्वारा उस तर्क के आह्वान को सुसंगत तरीके से लागू करने की नींव रखता है। इसका मतलब है कि आप कोड के दोहराव को कम / हटा भी सकते हैं, क्योंकि आपके ग्राहक समान सामान्य सेवाओं को साझा करते हैं। आप संभावित रूप से रखरखाव लागत को भी कम कर सकते हैं - जब आपका व्यवसाय तर्क बदलता है, तो आपको (आम तौर पर) केवल सेवा को बदलने की आवश्यकता होती है, और प्रत्येक क्लाइंट को नहीं।

सारांश में, यह एक सेवा परत का उपयोग करने के लिए अच्छा है - अधिक-इसलिए मुझे लगता है कि आपके उदाहरण में आपने प्रदान किया है क्योंकि यह लगता है जैसे आपके पास व्यावसायिक तर्क के कई ग्राहक हैं।

Comments

दिलचस्प बात यह है कि, मार्टिन फाउलर स्थानीय और दूरस्थ आह्वान के लिए एक ही इंटरफ़ेस के खिलाफ वकालत करते हैं, यह तर्क देते हुए कि दूरदराज के आह्वान में विशाल प्रदर्शन अंतर अधिक मोटे दाने वाले इंटरफ़ेस को मजबूर करता है।

— psr

मैं आपके पैराग्राफ को काफी नहीं समझ पाया With CRM, Sales and Inventory there will be a lot of CRUD-type use cases of which there is almost always a one-to-one correspondence with Service Layer operations- अगर यह सब कई UI के बारे में है तो यहाँ CRUD कैसे मिलता है? और अगर मुझे कई यूआई की जरूरत नहीं है, भले ही सीआरयूडी सेवाओं के साथ अच्छी तरह से चला जाता है मैं अभी भी एक सेवा परत नहीं बनाऊंगा, अगर मैं सही ढंग से समझ गया हूं, और मुझे वास्तव में उम्मीद है कि मैंने किया क्योंकि मैं चीजों को सरल रखना पसंद करता हूं (सेवा परत एक है मेरी अनुभवहीन राय को गड़बड़ करना)

— बॉर्नटोड

उन मामलों में यह दुर्लभ है कि केवल एक ग्राहक होगा जो इसका लाभ उठा सकता है। यदि आपके पास केवल एक UI है, तो मैं दो कारणों से सोच सकता हूं कि आप अभी भी सेवा की परत चाहते हैं: सुरक्षा और पुन: प्रयोज्यता। एक विशिष्ट उद्यम सेटअप में यूआई ऐप बाहरी ग्राहकों के लिए उपलब्ध होगा, और आपकी सेवा परत केवल नेटवर्क में उपलब्ध होगी। इसलिए वेब सर्वर आपके नेटवर्क के लॉक डाउन हिस्से के लिए काम को बढ़ा देता है। यदि आप अपनी वेब साइट से बिक्री लेते हैं और ईबे या अमेज़ॅन तक विस्तार करते हैं तो बिक्री उदाहरण में आप फिर से उपयोग कर सकते हैं। अब आपके पास एक यूआई है, फिर भी कई ग्राहक हैं।

— फिल पैटरसन

बस @PhilPatterson से टिप्पणी जोड़ने के लिए। एकाधिक क्लाइंट्स को केवल UI आधारित नहीं होना चाहिए। वेब सेवाओं या पुस्तकालयों के बारे में सोचें - वे ग्राहक भी हो सकते हैं। आपका फ्रंट एंड यूआई सर्विस लेयर के साथ-साथ आपके द्वारा पैकेज की गई सॉफ्टवेयर सेवाओं का उपयोग कर सकता है और किसी और को इस्तेमाल करने दे सकता है।

— डेको

क्या आप एक सेवा लेयर का उदाहरण प्रदान कर सकते हैं?

— user962206

Answer 2

सेवा परत जोड़ना क्योंकि आपने विचार का मूल्यांकन किया है और इसके सर्वोत्तम दृष्टिकोण का निष्कर्ष निकाला है: अच्छा

सर्विस लेयर जोड़ना क्योंकि यही सब कूल बच्चे कर रहे हैं: खराब

यदि आपका पेट कहता है कि आपको एक की जरूरत नहीं है, तो एक मत बनाओ।

पिछले 10 वर्षों में प्रोग्रामिंग की दुनिया में अधिक निराशाजनक घटनाक्रमों में से एक यह है कि यह ट्रेंड और बैंडवागन्स के बाद लोगों के साथ गुस्सा 'फैशन' उन्मुख हो गया है, जैसे कि वे इस सीजन के जूते थे। उस जाल में मत पड़ो। क्योंकि अगले सीज़न में 'हर' आपको बता रहा होगा कि आपको इसे किसी और तरह से डिज़ाइन करना चाहिए था।

सेवा परत के साथ कुछ भी गलत या सही नहीं है - यह एक विशेष दृष्टिकोण है जिसकी उपयुक्तता का मूल्यांकन इस परियोजना के लिए तकनीकी योग्यता के आधार पर किया जाना चाहिए। अपने स्वयं के निर्णय के लिए अन्य लोगों की राय को स्थानापन्न करने के लिए मजबूर महसूस न करें।

Comments

यह विषय वस्तु को बिल्कुल भी संबोधित नहीं करता है, यह सिर्फ विकास प्रथाओं के बारे में एक कंबल बयान / शेख़ी बनाता है, जो कुछ शब्दों को प्रतिस्थापित करने के बाद, इस साइट पर किसी भी प्रश्न के बारे में आवेदन कर सकता है। इस उत्तर को पढ़ने से, मुझे विश्वास भी नहीं हो रहा है कि आपको पता है कि सेवा की परत क्या है ।

— Aaronaught

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

— ग्रैंडमास्टरबी

@ जवाब के सही होने के बावजूद, वह अभी भी मुख्य प्रश्न का उत्तर दे रहा है, "सेवा की परत कितनी आवश्यक है?"। वह दावा नहीं करता है कि यह बिल्कुल जरूरी नहीं है और संभवतः यह केवल एक सनक है। यदि आप उत्तर से असहमत हैं तो कृपया नीचे जाएं।

— मेपल_शाफ्ट

@GrandmasterB मैं तर्क दूंगा कि सॉफ्टवेयर विकास में फैशन अच्छे हैं। अधिकांश डेवलपर्स अच्छी तरह से सूचित डिजाइन और वास्तुकला निर्णय लेने के लिए बहुत ताज़ा या अक्षम हैं। हम अभी भी उनसे काम करने वाले सॉफ्टवेयर के कुछ सदुपयोग को चालू करने की उम्मीद करते हैं, इसलिए वे एक बैंडवैगन पर कूदते हैं और एक खराब डिजाइन पसंद के अनुरूप होते हैं, जो कुछ साल पहले की चीजों की तुलना में बहुत बेहतर और अधिक रख-रखाव वाला है जहां हम हर चीज के लिए कोडिंग करेंगे। समझ में नहीं आया या सराहना।

— मेपल_शाफ्ट

@maple_shaft स्पष्ट करने के लिए, मैं यह नहीं कह रहा कि सेवा परतें एक सनक हैं। मैं कह रहा हूं, जिस तरह से सवाल पूछा गया था, उसके आधार पर ऐसा लगता है कि उसके सहयोगियों की ओर से सनक / फैशन / बैंडवागॉन व्यवहार है , जो उसे लगता है कि एक वास्तुकला का उपयोग करने के लिए उसे धक्का देना है जो उसके प्रोजेक्ट में निहित है। मैं अपने जवाब में यह स्पष्ट करता हूं कि मैं सर्विस लेयर्स (या किसी अन्य अवधारणा) को सिर्फ उस तटस्थ धारणाओं के रूप में देखता हूं जिसकी उपयुक्तता का मूल्यांकन व्यक्तिगत परियोजनाओं के लिए उनकी योग्यता के आधार पर किया जाना चाहिए। जब कोई अपना निर्णय कहता है कि उन्हें जरूरत है तो उन्हें लागू नहीं किया जाना चाहिए।

— ग्रैंडमास्टरबी

Answer 3

कई कारक हैं जो सर्विस लेयर बनाने के निर्णय में जाते हैं। मैंने निम्नलिखित कारणों से अतीत में सर्विस लेयर्स बनाए हैं।

1. ऐसे कोड जिन्हें कई क्लाइंट द्वारा फिर से उपयोग करने की आवश्यकता होती है।
2. तीसरे पक्ष के पुस्तकालय जिनके पास हमारे पास सीमित लाइसेंस हैं।
3. तृतीय पक्ष जिन्हें हमारे सिस्टम में एकीकरण बिंदु की आवश्यकता है।
4. डुप्लिकेट व्यवसाय तर्क को केंद्रीकृत करना।

केस 1: आप आधार कार्यक्षमता बना रहे हैं जिसका उपयोग विभिन्न ग्राहकों के असंख्य द्वारा किया जाना चाहिए। सेवा परत विभिन्न क्लाइंट्स के लिए कार्यक्षमता प्रदान करती है ताकि वे आपके द्वारा प्रदान की गई कार्यक्षमता को सीधे बॉक्स से बाहर कर सकें।

केस 2: आप आम तौर पर ऐप स्पेस में कोड होस्ट करते हैं लेकिन आप थर्ड पार्टी लाइब्रेरी का उपयोग कर रहे हैं जिसके लिए आपके पास सीमित लाइसेंस हैं। इस मामले में आपके पास एक संसाधन है जिसे आप हर जगह उपयोग करना चाहते हैं, लेकिन उनमें से केवल एक सीमित संख्या है। यदि आप इसे किसी सेवा के पीछे होस्ट करते हैं, तो आपका पूरा संगठन प्रत्येक व्यक्तिगत होस्टिंग के लिए लाइसेंस खरीदने के बिना अपने अनुप्रयोगों से इसका उपयोग कर सकता है।

केस 3: आप से संवाद करने के लिए आप तीसरे पक्ष के लिए कार्यक्षमता का निर्माण कर रहे हैं। आपके उदाहरण में आप आने वाले उत्पाद शिपमेंट के बारे में विक्रेताओं को संदेश भेजने की अनुमति देने के लिए एक इन्वेंट्री समापन बिंदु सेट कर सकते हैं।

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

यह सब कहा जा रहा है कि एक सेवा परत के लिए संभावित नकारात्मक हैं।

1. सिस्टम जटिलता जोड़ता है। जहां पहले आपके पास केवल एक आवेदन डिबग करने के लिए था अब आपके पास दो हैं। उत्पादन समस्याओं के लिए क्लाइंट ऐप सेटिंग, सेवा ऐप सेटिंग, या संचार समस्याओं के बीच सही ढंग से सेटअप क्लाइंट और सर्वर ऐप की जाँच करना आवश्यक है। यह मुश्किल हो सकता है अगर आपने इसे पहले कभी नहीं किया है।
2. असफलता का एक बिंदु। यदि आपके पास सर्विस आउटेज है तो सभी क्लाइंट प्रभावित होते हैं। जब इस तरीके से कोड को तैनात नहीं किया जाता है, तो जोखिम कम हो सकता है (हालांकि इसे कम करने के तरीके हैं)।
3. वर्जन करना कठिन हो सकता है। जब आपके पास एक ऐप होता है, तो एक सेवा का उपयोग करते हुए इंटरफ़ेस परिवर्तन दोनों के बीच एक ही समय में किया जा सकता है। जब आपके पास एक से अधिक ग्राहक हैं, तो आपको यह प्रबंधित करना होगा कि V1 पर कौन है, जो V2 पर है, और V1 को हटाने का समन्वय कर रहा है (एक बार जब आप जानते हैं कि सभी ने V2 को अपडेट कर दिया है)।

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

Comments

+1 जानकारीपूर्ण उत्तर के लिए धन्यवाद। मुझे आपके उत्तर या डेको के उत्तर को स्वीकार करने के लिए वास्तव में संदेह था। आखिरकार क्योंकि मैं बहुत अनुभवी नहीं हूं, इसलिए मैंने उस उत्तर को चुनने का फैसला किया, जो सबसे ऊपर जाता है। मुझे अब भी लगता है कि आपके उत्तर में अधिक उत्थान होगा। किसी भी घटना में मैं वास्तव में सराहना करता हूं कि आपने अपने ज्ञान और अनुभव को साझा किया। धन्यवाद!

— बॉर्नटोड कोड

आपका स्वागत है! दोनों उत्तरों को हटाने का मुख्य बिंदु यह है कि यह (मुख्य रूप से) कई ग्राहकों के साथ रखरखाव के मुद्दों को हल करने के बारे में है जो एक ही काम करने की आवश्यकता है। सेवा का उपयोग करने वाले ग्राहकों की अधिक संख्या, आपके लिए रखरखाव का बड़ा लाभ।

— फिल पैटरसन

वहाँ भी सुरक्षा है - सेवा की परतें डीबी में खजाने को प्राप्त करने के लिए हैकर्स के लिए एक और दीवार प्रदान कर सकती हैं। सर्विस लेयर्स की कमी शायद इसीलिए है कि कई वेबसाइट्स को भारी छूट मिलती है, बीच में सर्विस के साथ हैकर्स को पता लगने से पहले काफी कम डेटा मिलता है।

— gbjbaanb 13

Answer 4

मैंने देखा है कि अधिकांश सेवा परतें पूरी तरह से गड़बड़ हैं। सेवाओं में बहुत सारे अलग-अलग तरीके हैं, 1500 LOC दुर्लभ नहीं हैं। विभिन्न विधियों में कुछ भी सामान्य नहीं है, लेकिन शेयर कोड है। इसके परिणामस्वरूप उच्च युग्मन , कम सामंजस्य होता है । यह OCP का भी उल्लंघन करता है , क्योंकि हर बार एक नए ऑपरेशन की आवश्यकता होती है, आपको कोड आधार को बढ़ाने के बजाय कोड को संशोधित करना होगा। एक अच्छी तरह से निर्मित सेवा परत सैद्धांतिक रूप से संभव है, लेकिन मैंने इसे अभ्यास में कभी नहीं देखा।

CQRS इन समस्याओं को हल करता है और आपको उन प्रक्रियात्मक सेवा परतों में से एक बनाने से रोकता है।

Comments

हालांकि किसके मानकों से निर्मित है? निश्चित रूप से OO मानकों के अनुसार एक सर्विस लेयर इंटरफेस मेस का पूरा ट्रेनवॉक है। एक कार्यात्मक या प्रक्रियात्मक दृष्टिकोण से यह एक सुंदर स्तरित डिजाइन दृष्टिकोण को प्रोत्साहित करता है। मुझे लगता है कि लोगों की सेवा परतों के साथ सबसे बड़ा हैंग है कि वे एक स्टेटलेस ट्रांजेक्शन आधारित एप्लिकेशन को प्रोत्साहित करते हैं और शुद्ध वस्तु उन्मुख दृष्टिकोण को हतोत्साहित करते हैं। मैं तर्क के दोनों पक्षों को समझ सकता हूं।

— मेपल_शफ्ट

Answer 5

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

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

यदि आप जानते हैं, इस तथ्य के लिए, कि आज आप जो कार्यक्षमता लिख ​​रहे हैं, उसका कई अलग-अलग सेवा ग्राहकों द्वारा पुन: उपयोग किया जाएगा, तो एक दिन से एक सेवा परत को डिजाइन करने पर विचार करें। यदि आप अनिश्चित हैं, या पहले से ही प्रोजेक्ट में कई अज्ञात हैं, तो पहले कुछ सरल काम करें और बाद में आपके पास समय और बजट होने पर इसे सेवा और क्लाइंट में अलग कर दें। जब आप एक कार्य प्रणाली के साथ शुरू करते हैं, तो पहले प्रयास में सर्विस इंटरफेस को प्राप्त करना बहुत आसान है।

पुनश्च यदि आप जावा में काम कर रहे हैं, जोशुआ बलोच ने अपनी पुस्तक, प्रभावी जावा में शानदार इंटरफ़ेस सलाह दी है।

Comments

बाँझ सिद्धांतों के बिना एक महान जवाब।

— डेनिलो

Answer 6

मैं आपसे सहमत हुँ। यदि आप एक यूआई का उपयोग कर रहे हैं तो एक और परत शामिल करने की कोई आवश्यकता नहीं है।

डीएएल, बीएल और यूआई / नियंत्रक एक एप्लिकेशन को डिजाइन करने के लिए अच्छा संयोजन है। यदि आप एकल यूआई के साथ जाने की योजना बना रहे हैं, तो एक अतिरिक्त परत तैयार करने की आवश्यकता नहीं है। आवेदन में 1 और परत शामिल करने से केवल विकास प्रयास / समय बढ़ता है।

एक अन्य श्रोता अपने आवेदन में कई यूआई का उपयोग करने के लिए है, इस मामले में यूआई को संभालने के लिए एक सेवा परत होना अच्छा है।

स्टैक ओवरफ्लो: सर्विस लेयर पैटर्न पर चर्चा

Comments

तो क्या आप यह सुझाव देते हैं कि प्रत्येक जटिल अनुप्रयोग पर एक विकासकर्ता को एक सेवा स्तर का उपयोग करना चाहिए और न केवल डीएएल, बीएल, यूआई परतों के लिए समझौता करना चाहिए?

— बॉर्नटूकोड

कई यूआई के मामले में हमें एक सेवा परत शामिल करनी चाहिए। आपके मामले में मुझे नहीं लगता कि एक नई परत तैयार करने की आवश्यकता है। यह केवल आवेदन की जटिलता को बढ़ाता है।

— सतीश पांडे

Answer 7

मुझे लगता है कि आपका बीएल आपकी सेवा की परत है। एक केंद्रीय स्थान जहां आपका व्यावसायिक तर्क बैठता है। यह एक DLL होना चाहिए जिसका उपयोग उस तर्क की आवश्यकता वाले किसी भी चीज़ के द्वारा किया जा सकता है। फिर आप उसके ऊपर एक वेब एपि लेयर रख सकते हैं यदि आपके ऐप में अलग यूआई होगा।