क्या हमें उसी समाधान में एमवीसी एप्लिकेशन से वेब एपीआई को कॉल करना चाहिए?

मैं एमवीसी में एक परियोजना पर काम कर रहा हूं जिसमें मोबाइल एप्लिकेशन है इसलिए एक बात स्पष्ट है कि हमें वेब एपीआई का उपयोग करना होगा इसलिए इसका उपयोग मोबाइल एप्लिकेशन में किया जा सकता है।

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

मुझे इस समाधान संरचना के बारे में भ्रम हो रहा है।

1) हमें वेब एपीआई का उपयोग क्यों करना चाहिए और सीधे व्यावसायिक वस्तु के बजाय डेटा प्राप्त करने या लगाने के लिए HTTP अनुरोध (जो कि समय लेने वाला है) बनाना चाहिए जो उसी समाधान में है।

2) बहस होने के बाद उन्होंने कहा कि यदि ग्राहक एपीआई और वेब को अलग-अलग क्लाउड सर्वर पर होस्ट करना चाहता है और केवल एपीआई पर स्केलिंग लागू करता है या हो सकता है कि वह एपीआई और वेब तक पहुंचने के लिए अलग-अलग यूआरएल चाहता है (जो कि कुछ तार्किक है)। तो क्या उस मामले में हमें उसी समाधान में एमवीसी एप्लिकेशन से वेब एपीआई को कॉल करना चाहिए?

3) यदि हम अलग-अलग होस्टिंग पर एपीआई और वेब की मेजबानी कर रहे हैं तो इसका मतलब है कि हमारा वेब वेबक्लाइंट का उपयोग करेगा और प्रत्येक नेविगेशन पर HTTP कॉल करेगा। क्या यह सही है?

4) यदि हम व्यापार वस्तु को अलग-अलग सर्वर पर एपीआई और वेब होस्टिंग दोनों बनाते हैं तो यदि बीएल में कुछ बदलाव के लिए दोनों सर्वर पर बिल्ड अपडेट करना होगा।

5) या हमें एपीआई के लिए केवल एक प्रोजेक्ट बनाना चाहिए और वेब इंटरफेस विकसित करने के लिए विचार या HTML पेज जोड़ सकते हैं ताकि इस तरह से हम सीधे अजाक्स से एपीआई कॉल कर सकें।

मेरे ज्ञान के अनुसार # 5 सबसे अच्छा समाधान है या एपीआई केवल 3 पार्टी एक्सेस के लिए है। अगर हमारे पास DB, EF, डेटा लेयर और बिज़नेस लेयर एक ही सॉल्यूशन में हैं, तो हमें HTTP कॉल्स करने और सीधे बिज़नेस ऑब्जेक्ट को एक्सेस करने के लिए API का उपयोग नहीं करना चाहिए। (मुझे सही करें अगर मैं गलत हूं) मोबाइल एप्लिकेशन या डेस्कटॉप या किसी एक को एप्लिकेशन एक्सेस करने की आवश्यकता होने पर एपीआई की आवश्यकता होती है ताकि हमारे पास समान रिपॉजिटरी और डेटा लेयर हो सके।

मेरे परिदृश्य में मुझे एपीआई बनाना है क्योंकि हमारे पास मोबाइल एप्लिकेशन भी है, और प्रोजेक्ट एपीआई पक्ष में हमने व्यावसायिक परत (अलग परियोजना) और व्यावसायिक परत को डेटा एक्सेस लेयर (अलग परियोजना) के लिए संवाद किया है। तो मेरा प्रश्न यह है कि अगर हम अपने एपीआई और वेब को अलग-अलग सर्वरों में होस्ट करते हैं तो एपीआई को कॉल करना जो एक HTTP अनुरोध है, व्यवसाय परत से विधि का उपयोग करने के बजाय अधिक समय ले सकता है क्योंकि हम परियोजना बनाते हैं और हम व्यापार परत की .dll करते हैं। API कंट्रोलर में हम अपने व्यवसाय के पुट को json फॉर्मेट में बदल देते हैं।

मैंने इंटरनेट पर खोज की है, लेकिन ठोस जवाब नहीं मिला। मैंने एक ब्लॉग http://odetocode.com/blogs/scott/archive/2013/07/01/on-the-coexistence-of-asp-net-mvc-and-webapi.aspx पर एक ही बिंदु पर चर्चा करते हुए पाया है उस ब्लॉग में मेरा प्रश्न यह है कि हमें परिदृश्य # 3 पर विचार करने की आवश्यकता क्यों है?

अद्यतन: हमारे पास अलग-अलग एपीआई परियोजना और एमवीसी परियोजना हो सकती है और हम जावास्क्रिप्ट का उपयोग करके वेब से एपीआई कॉल कर सकते हैं या एमवीवीएम पैटर्न का उपयोग कर सकते हैं।

— रुचिर शाह
स्रोत

एमवीवीएम या एमवीसी व्यू मॉडल के साथ?

— एंड्रयू हॉफमैन

हम MVC

— रुचिर शाह

ठीक है, तो वास्तव में कोई सही जवाब नहीं है। जब आपकी गुणवत्ता में सुधार की बात आती है तो केवल आपके एपीआई को कॉल करने के लाभ हैं। (अपने खुद के डॉगफूड खाने) सेवाओं के माध्यम से कॉल करने के बजाय inproc कॉल करने के लिए प्रदर्शन लाभ भी हैं।

— एंड्रयू हॉफमैन

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

— एंड्रयू हॉफमैन

हाँ। programmers.stackexchange.com/questions/148556/… और stackoverflow.com/questions/3590561/… अच्छे संसाधन हैं। कुछ करते हैं, कुछ नहीं करते। कोई वास्तविक 'सही' तरीका नहीं।

— एंड्रयू हॉफमैन

जवाबों:

बड़ा अच्छा सवाल! मैं हमेशा अपनी परियोजनाओं की संरचना के लिए एक बेहतर तरीके की तलाश में हूं .. आपके द्वारा उठाए गए प्रत्येक बिंदु में योग्यता है और विभिन्न प्रकार की समाधान संरचनाओं का पता लगाने के लिए मुझे यह कहना होगा कि मैं यहां अधिकांश टिप्पणियों से सहमत हूं: कोई भी सही समाधान नहीं है। इस तरह की समस्या का सामना करने पर कुछ चीजें खुद से पूछें: यह आवेदन कितना जटिल है? मुझे कितनी प्रणालियों के साथ एकीकृत करने की आवश्यकता होगी - या इस प्रणाली के साथ कितनी प्रणालियों को एकीकृत करने की आवश्यकता होगी? मैं कितना परीक्षण करने की योजना बना रहा हूं? क्या एक अलग डिजाइन / यूआई टीम है? क्या हमें पैमाना बनाने की आवश्यकता होगी? क्या एक सत्र का गठन?

आइए कुछ चीजों को वास्तव में धमाकेदार बनाने के लिए परिदृश्यों के कुछ तरीकों और तरीकों का उपयोग करें (और चीजों को थोड़ा आसान बनाने के लिए कुछ ट्रिक्स) ..

समान परियोजना
में दोनों एपीआई और वेबसाइट की मेजबानी करना इस मामले में, आपके पास शून्य या अधिक व्यावसायिक परत परियोजनाओं और एक एकल हाइब्रिड एमवीसी / वेबएपीआई परियोजना (साथ ही अन्य परियोजनाएं - उपयोगिता, आदि) के साथ एक समाधान हो सकता है।

प्रो की
सब कुछ एक ही जगह पर है .. जटिल मैसेजिंग (HttpClient कॉल्स) में जूता-हॉर्न की जरूरत नहीं है, आप साझा सत्र स्थिति (कुकीज़, InProc / OutOfProc सत्र, आदि), कनेक्शन पूलिंग, साझा लॉजिक, आदि के माध्यम से साझा कर सकते हैं। परिनियोजन अधिक सरल नहीं हो सकता है।

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

उपयोग
मैं इस परियोजना संरचना का उपयोग एकबारगी, आंतरिक या सरल अनुप्रयोग के लिए करूंगा। स्थानीय Y पर बास्केटबॉल कैंप साइन-अप पर नज़र रखने के लिए एक त्वरित प्रणाली का निर्माण? यह आपकी वास्तुकला है!

विभिन्न परियोजनाओं में वेबएपीआई और वेबसाइट
मैं इस मामले को पसंद करते हैं .. आपके पास एक (या अधिक) एमवीसी परियोजना (एस) और एक वेबएपीआई परियोजना के साथ एक ही समाधान है।

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

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

उपयोग करता है
कि एक आवेदन है कि आज 100 उपयोगकर्ताओं और अगले सप्ताह / महीने हो सकता है बिल्डिंग? क्या एप्लिकेशन को सूचनाएं भेजनी हैं, जटिल वर्कफ़्लो का प्रबंधन करना है, और कई इंटरफेस (वेब + मोबाइल ऐप + SharePoint) हैं? अपने हाथों पर बहुत समय है और सप्ताहांत में 5000+ पहेली हल करना पसंद करते हैं? यह आपके लिए वास्तुकला है!

ऊपर बताई गई युक्तियां , मैं समझ सकता हूं कि आपकी अगली परियोजना थोड़ी कठिन लग सकती है। कोई चिंता नहीं, यहाँ कुछ चालें मैं वर्षों से सीखा है ..

स्टेटलेस सेशन का इस्तेमाल करने की कोशिश करें। छोटे सिस्टम पर, इसका मतलब हो सकता है एक एन्क्रिप्टेड कुकी को स्टोर करना जिसमें कम से कम वर्तमान उपयोगकर्ता की आंतरिक आईडी और एक टाइमआउट हो। बड़े सिस्टम का मतलब हो सकता है कि एक साधारण सत्र आईडी के साथ एक एन्क्रिप्टेड कुकी को संग्रहीत करना, जो डेटासटोर (रेडिस, टेबल स्टोरेज, डीएचटी , आदि) से प्राप्त किया जा सकता है .. यदि आप पर्याप्त जानकारी स्टोर कर सकते हैं ताकि आपको मुख्य डेटाबेस को हिट न करना पड़े। हर अनुरोध पर तब आप एक अच्छी जगह पर होंगे - लेकिन कुकीज़ को 1k से कम रखने की कोशिश करें।
ज्ञात हो कि संभवतः एक से अधिक मॉडल होंगे। मॉडल और अनुमानों के संदर्भ में सोचने की कोशिश करें (जो लिंक मुझे यहां मिले .. अच्छे नहीं थे .. सोचते हैं: एक आदमी की इन्वेंट्री आइटम किसी अन्य व्यक्ति की ऑर्डर लाइन आइटम है - एक ही मूल अंतर्निहित संरचना, लेकिन अलग-अलग विचार)। कुछ परियोजनाओं में प्रत्येक तार्किक / वैचारिक सीमा के लिए एक अलग मॉडल होता है (यानी एक विशिष्ट एपीआई के साथ सांप्रदायिकता के लिए एक विशिष्ट मॉडल का उपयोग करना।
एपीआई हर जगह! किसी भी समय एक वस्तु / वर्ग / संरचना किसी भी डेटा या व्यवहार को उजागर करती है, आप एक एपीआई स्थापित कर रहे हैं। इस API का उपयोग करने वाली अन्य संस्थाएँ या निर्भरताएँ किस तरह से ध्यान रखेंगी। इस बारे में सोचें कि आप इस एपीआई का परीक्षण कैसे कर सकते हैं। इस एपीआई पर विचार करें कि क्या हो सकता है (कोड के माध्यम से अन्य ऑब्जेक्ट? एक प्रोटोकॉल के माध्यम से अन्य सिस्टम?) और कैसे उस डेटा को उजागर किया जाता है (दृढ़ता से टाइप किया गया? JSON? * खांसी * XML?)।
आपके पास जो है उसके लिए निर्माण करें, न कि वह जो आप कल्पना करते हैं कि आपके पास अभी से दो साल होंगे। एक अन्य उत्तर YAGNI का संदर्भ देता है - वे बिल्कुल सही हैं! काल्पनिक समस्याओं को हल करने से आपकी समय सीमा काल्पनिक बन जाती है। अपने पुनरावृत्तियों के लिए ठोस लक्ष्य निर्धारित करें और उनसे मिलें। तैनाती! विकास में एक परियोजना केवल एक उपयोगकर्ता के साथ एक परियोजना है - आप!
YMMV (आपका माइलेज मई वैरी)। यहां केवल एक ही निरपेक्ष है: एक समस्या है, आप एक समाधान का निर्माण कर रहे हैं। बाकी सब कुछ पूरी तरह से हवा में है। उपरोक्त दोनों समाधानों को एक जंगली सफलता - और एक चूसने की विफलता बनाया जा सकता है। यह आप पर निर्भर है, आपके उपकरण और आप उनका उपयोग कैसे करते हैं। हल्के से चलना, साथी डेवलपर!

— बॉबी डी
स्रोत

बहुत बढ़िया जवाब! काश, मैं आपको आपके लेखन के लिए कुछ पुरस्कार दे सकता, लेकिन चूंकि मैं कुछ भी नहीं सोच सकता, मैं सिर्फ आपके ट्विटर का अनुसरण करूंगा। : पी

— दान

"जोर से टाइप किया? JSON? * खांसी * XML" मुझे क्या याद आ रही है?

— अलेक्जेंडर डर्क

@AlexanderDerck मैं तीन अलग-अलग प्रारूपण विकल्पों का उल्लेख कर रहा हूं (हालांकि अधिक हैं) .. "मजाक" यह है कि एक्सएमएल के साथ काम करना मुश्किल हो सकता है और अक्सर ओवरहेड (सीरियलाइज़ेशन / डीसर्लाइज़ेशन) का एक अच्छा सा जोड़ सकता है। यह कहने की ज़रूरत नहीं है कि कभी-कभी ज़रूरत नहीं होती है (विशेषकर बाहरी समूहों के साथ काम करते समय) ..

— बॉबी डी

सीधे आपकी व्यावसायिक वस्तुओं तक सीधे पहुंचना (मेरा मानना है कि आप अपने कंट्रोलर से मतलब रखते हैं) तेज और आसान होगा।

क्या होगा यदि क्लाइंट अलग-अलग क्लाउड सर्वर पर एपीआई और वेब होस्ट करना चाहता है और केवल एपीआई पर स्केलिंग लागू करता है या हो सकता है कि वह एपीआई और वेब तक पहुंचने के लिए अलग-अलग यूआरएल चाहता है (जो कुछ तार्किक है)

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

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

— Rocklan
स्रोत

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

— ईशोर खानल

में कहना चाहूंगा; HTTP क्लाइंट के माध्यम से वेबएपीआई कॉल करने वाले MVC को पसंद करें। यह "कोर dll" लॉजिक के बारे में अधिक जानकारी देता है लेकिन मुख्य लाभ यह है कि आपके समग्र सिस्टम में HTTP पर डोमेन ऑब्जेक्ट्स के लिए एक सिंगल पॉइंट एक्सेस होगा ... वैसे भी लाइन से नीचे .. माइक्रो सर्विस आर्किटेक्चर पिक-अप और ऐप्स पहले से ही स्विच हो रहे हैं क्लाइंट साइड फ्रेमवर्क (AngularJS etc।) .... MVC को एक अन्य ग्राहक के रूप में बेहतर माना जाता है ... और अपनी टीम को प्रबंधित करने के लिए अपनी टीम को शिष्य बनाएं ...

KEEP IT SIMPE। उममीद है कि इससे मदद मिलेगी। धन्यवाद..

— मनोज कुमार बिष्ट
स्रोत

निश्चित नहीं है कि यह मतदान क्यों किया गया था लेकिन यह अच्छी वास्तुकला के लिए सबसे अच्छा उत्तर है imo

— weagle08

मैं अपनी स्थिति पर विचार कर रहा था जहां मुझे लगा कि खुद के एमवीसी ऐप से एपीआई कॉल करना एक अच्छा विचार है- लेकिन मुझे लगता है कि यह इससे अलग है और शायद कई अन्य प्रश्न हैं जो सर्वर लॉजिक से इस कॉल को संदर्भित करते हैं। मेरे मामले में मैं वास्तव में इसे अपने विचारों से कह रहा हूँ जहाँ मुझे Vue बनाने और जटिल UI बनाने और डेटा को उस API पर भेजने की आवश्यकता होगी। तब मुझे एहसास हुआ कि यह वैध है क्योंकि मेरे मामले में यह वास्तव में सर्वर-साइड आइटम के दृश्य से कॉल कर रहा है और किसी भी तरह के UI पर विचार करते समय किसी भी तरह से http कॉल किया गया होगा- शायद और भी अधिक अगर एएसपी-निर्मित विचार। लेकिन, केवल जेएस वातावरण में काम करता है।

— वसीली हॉल

सीधे कॉल करना देखें एपीआई एक अच्छा विचार है .... लेकिन एमवीसी व्यू सर्वर से उत्पन्न होते हैं इसलिए आप आंशिक विचारों (दृश्य) को प्रस्तुत करने से पहले सर्वर से डेटा (विशेष रूप से सर्वर प्रोसेसिंग के लिए अधिक प्रासंगिक) को संसाधित कर सकते हैं ... RESS फ्रेमवर्क (RESS : उत्तरदायी वेब डिज़ाइन + सर्वर-साइड घटक) .... लेकिन अगर आप MVC से पूरी तरह से बच सकते हैं तो सबसे अच्छा उपयोग ग्राहक फ्रेमवर्क (कोणीय / ReactJS) करें ...

— मनोज कुमार बिष्ट