अलग परियोजना में एमवीसी समाधान में वेब एपीआई

Question

मैं एक नया MVC4 प्रोजेक्ट बना रहा हूं, और अनुसंधान ने मुझे यह विश्वास करने के लिए प्रेरित किया है कि जावास्क्रिप्ट से सर्वर साइड तक संचार करना बेहतर ढंग से नियंत्रक क्रियाओं के बजाय वेब एपीआई फ्रेमवर्क के माध्यम से अब प्राप्त किया गया है। क्या मेरी समझ इस पर सही है?

मैं मान रहा हूं कि मैं वेब एपीआई और एमवीसी नियंत्रकों के बीच अपनी सभी विशेषताओं आदि को साझा कर सकता हूं, इसलिए चेहरे पर यह मेरे लिए एक बड़ा बदलाव नहीं लगता है।

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

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

Answer 1

दुर्भाग्य से आप इसके बारे में गलत हैं - मैं मान रहा हूं कि मैं अपने सभी विशेषताओं आदि को वेब एपी और एमवायएक्स नियंत्रकों के बीच साझा कर सकता हूं ताकि चेहरे पर यह मेरे लिए एक बड़ा बदलाव न लगे।

वेब एपीआई और एमवीसी द्वारा उपयोग की जाने वाली कई अवधारणाएं, भले ही पहली नज़र में समान हों, वास्तव में संगत नहीं हैं। उदाहरण के लिए, वेब एपीआई विशेषताएँ हैं System.Web.Http.Filters.Filterऔर एमवीसी विशेषताएँ हैं System.Web.Mvc.Filter- और वे विनिमेय नहीं हैं।

समान कई अन्य अवधारणाओं पर लागू होता है - मॉडल बाइंडिंग (पूरी तरह से अलग तंत्र), मार्ग (वेब ​​एपीआई HTTPRoutes का उपयोग करता है रूट नहीं, भले ही वे दोनों एक ही अंतर्निहित मार्ग पर काम करते हैं), निर्भरता रिज़ॉल्वर (संगत नहीं) और अधिक - भले ही समान पर सतह, व्यवहार में बहुत अलग हैं। इसके अलावा, वेब एपीआई में क्षेत्रों की अवधारणा नहीं है।

अंततः, यदि आप सभी प्राप्त करने की कोशिश कर रहे हैं, तो JSON सामग्री परोसने का "नया, ट्रेंडी" तरीका है - उस रास्ते पर जाने से पहले दो बार सोचें। मैं निश्चित रूप से किसी भी मौजूदा कोड को फिर से शुरू करने की सिफारिश नहीं करूंगा जब तक कि आप वास्तव में एचटीटीपी को गले लगाने और अपने ऐप को एक शानदार तरीके से बनाने की कोशिश नहीं कर रहे हैं।

यह सब वास्तव में आप क्या निर्माण कर रहे हैं पर निर्भर करता है। यदि आप एक नई परियोजना शुरू कर रहे हैं, और आप सभी की जरूरत है अपने वेब अनुप्रयोग की सुविधा के लिए कुछ JSON की सेवा करने के लिए है - बशर्ते आप कुछ संभावित डुप्लिकेट कोड के साथ रहने के लिए तैयार हों (जैसे कि ऊपर उल्लेखित सामान), वेब एपीआई को आसानी से होस्ट किया जा सकता है ASP.NET MVC के रूप में एक ही परियोजना।

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

Comments

+1 उत्कृष्ट उत्तर। मुझे लगा कि शुरू में MVC और WebAPI दोनों कुछ कोड को विशेष रूप से फ़िल्टर, मॉडल बाइंडिंग आदि के मामले में साझा कर सकते हैं, लेकिन वे पूरी तरह से अलग हैं।

— वीजेएआई

इस तरह के परिदृश्य में हाँ, Visual Studio में एक नई MVC4 परियोजना शुरू करें, और जब एक प्रोजेक्ट टेम्पलेट (दूसरी स्क्रीन) के लिए कहा जाए तो बस Web API का चयन करें। यह Nuget से Web API स्थापित करेगा और आपके द्वारा वर्णित मामले में पूरी तरह से ठीक होना चाहिए। आपको जो मिलता है वह है अलग वेब एपीआई कॉन्फिग फाइल Global.asax में प्लग किया गया। इसके अतिरिक्त आप एपीआई कंट्रोलर को अलग फ़ोल्डर में अलग कर सकते हैं (डिफ़ॉल्ट रूप से वे एमवीसी नियंत्रकों के साथ हैं)। अंत में, डिफ़ॉल्ट मार्गों को स्पष्ट रूप से अलग से कॉन्फ़िगर किया गया है और एक दूसरे के साथ हस्तक्षेप नहीं करते हैं

— फिलिप डब्ल्यू

काश मेरे लीडर ने हमारे वर्तमान प्रोजेक्ट को डिजाइन करने से पहले इस पोस्ट को पढ़ा होता।

— बिल्र्ड

@FilipW अच्छी व्याख्याओं के लिए धन्यवाद। मेरे पास MVC एप्लिकेशन भी है और Android एप्लिकेशन के लिए सेवा का उपयोग करने के लिए WebAPI2 का उपयोग करेगा। दूसरी ओर, जैसा कि डेविड पेडन नीचे कहते हैं, वेबएपीआई के लिए एक नया अलग प्रोजेक्ट बनाने का निर्णय लेते समय सुरक्षा, रखरखाव और तैनाती भी बहुत महत्वपूर्ण है। उस मामले में, उन्हें ध्यान में रखते हुए, आप क्या सुझाव देंगे? WebAPI के लिए एक नया अलग प्रोजेक्ट बनाने के लिए या वर्तमान MVC प्रोजेक्ट का उपयोग करने के लिए? अग्रिम में धन्यवाद।

— जैक

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

— ozzy432836

Answer 2

IMO, सुरक्षा और परिनियोजन को आपके निर्णय को चलाना चाहिए। उदाहरण के लिए, यदि आपका MVC एप्लिकेशन फ़ॉर्म प्रमाणीकरण का उपयोग करता है, लेकिन आप अपने API के लिए मूलभूत प्रमाणीकरण (SSL के साथ) का उपयोग करने में रुचि रखते हैं, तो अलग-अलग प्रोजेक्ट आपके जीवन को आसान बनाने जा रहे हैं। यदि आप www.example.com पर yout साइट को होस्ट करना चाहते हैं, लेकिन अपने API को api.example.com (बनाम www.example.com/api) के रूप में होस्ट करते हैं, तो अलग-अलग प्रोजेक्ट आपके जीवन को आसान बना देंगे। यदि आप अपनी परियोजनाओं को अलग करते हैं और तदनुसार उन्हें उप-डोमेन करते हैं और आप अपने एमवीसी ऐप से अपने स्वयं के एपीआई का लाभ उठाने का इरादा रखते हैं, तो आपको यह पता लगाना होगा कि क्लाइंट-साइड कॉल के लिए अपने एपीआई के लिए समान उत्पत्ति नीति मुद्दे से कैसे निपटें । इसके लिए सामान्य उपाय हैं कि jsonp या CORS का लाभ उठाया जाए (अधिमानतः यदि आप कर सकते हैं)।

अपडेट (3/26/2013): आधिकारिक CORS समर्थन आ रहा है: http://aspnetwebstack.codeplex.com/wikipage?title=CORS%20support%20for%20ASP.NET%20Web%20API

Comments

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

— सियारन गलाघेर

व्यक्तिगत रूप से, मैं आपके एपीआई के लिए आपके डीटीओ के रूप में आपके विचार मॉडल का उपयोग नहीं करूंगा। मुझे उम्मीद है कि उस फैसले से आपको सड़क पर कुछ गंभीर दर्द हो सकता है क्योंकि आपके दृश्य मॉडल और एपीआई हस्ताक्षर गोताखोर हैं। SoC ( en.wikipedia.org/wiki/Separation_of_concerns ) बहुत महत्वपूर्ण है।

— डेविड पेडन

@DavidPeden आप WebAPI के लिए एक नया अलग प्रोजेक्ट बनाने का सुझाव देते हैं। क्या यह सच है? दूसरी ओर, मैं अपने आवेदन में वेबएपीआई (मेरे पास वर्तमान में एक यूआई लेयर (एमवीसी) और डेटा लेयर (क्लास लाइब्रेरी) है) के लिए एक अलग प्रोजेक्ट बनाऊंगा। इसलिए, मैं डीआई का भी उपयोग करता हूं, लेकिन मैं सोच रहा हूं कि क्या मैं उपयोग कर सकता हूं। नए बनाए गए वेबएपीआई प्रोजेक्ट के लिए डेटा लेयर में समान एंटिटीज, रिपॉजिटरी, इंटरफेसेस और एब्सट्रैक्ट क्लास और केवल एक चीज जो मुझे करनी है वह है वेबएपीआई कंट्रोलर बनाना? या क्या मैं उन सभी (एंटिटीज, रिपोजिटरीज, इंटरफेसेस और एब्सट्रैक्ट को भी बनाता हूं? कक्षाएं) फिर से वेबएपीआई के लिए? कोई मदद कृपया?

— जैक

@ एच। जॉनसन यह सामान्य सलाह देना कठिन है कि यह सार्थक है, लेकिन ऐसा लगता है कि आपको एक आवेदन सेवा परत होने से लाभ होगा जो आपकी संस्थाओं और रिपॉजिटरी को एन्क्रिप्ट करता है जो आपके यूआई (एमवीसी और एपीआई) दोनों द्वारा लीवरेज किया जा सकता है।

— डेविड पेडेन

Answer 3

कुछ हद तक अनुभव के बाद (ऐप्स के लिए एपीआई और पीवीसी के लिए)। मैं ज्यादातर दोनों करते हैं।

मैं अन्य ग्राहकों या अन्य उपकरणों (Android / IOS ऐप्स) से आने वाले एप कॉल के लिए एक अलग प्रोजेक्ट बनाता हूं। कारणों में से एक है क्योंकि प्रमाणीकरण अलग है, यह टोकन आधारित है (इसे स्टेटलेस रखने के लिए)। मैं अपने MVC एप्लिकेशन में इसे नहीं मिलाना चाहता।

मेरे जावास्क्रिप्ट एप्लिकेशन के लिए मेरी जावास्क्रिप्ट / jquery एपीआई कॉल के लिए, मैं चीजों को सरल रखना पसंद करता हूं इसलिए मैं अपने एमवीसी एप्लिकेशन के अंदर एक वेब एपीआई शामिल करता हूं। मेरा जावास्क्रिप्ट एपीआई कॉल के साथ टोकन आधारित प्रमाणीकरण का इरादा नहीं है, क्योंकि हे, यह एक ही आवेदन में है। मैं केवल [authorize]एपीआई एंडपॉइंट पर विशेषता का उपयोग कर सकता हूं , जब कोई उपयोगकर्ता लॉग इन नहीं होता है, तो उसे डेटा नहीं मिलेगा।

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

Comments

खैर @Dimi, कि कुछ वोट पाने के लिए एक बेकार संपादन है ... मैं इन्हें कैसे अस्वीकार कर सकता हूं?

— CularBytes

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

— दिमित्रीबॉयको

@CularBytes आप संपादन अस्वीकार नहीं कर सकते, लेकिन आप इसे फिर से संपादित कर सकते हैं और परिवर्तनों को रोलबैक कर सकते हैं। इसके लिए 2,000 प्रतिनिधि के तहत एक सहकर्मी समीक्षा प्रक्रिया की आवश्यकता होती है, लेकिन आपके पास इसे तुरंत करने के लिए पर्याप्त प्रतिनिधि है। मैं मानता हूं कि संपादन ने कोई मूल्य नहीं जोड़ा है और इसे आपके लिए वापस ले लिया है।

— डैन बेचर

Answer 4

SimpleInjector (IoC ढांचे) से स्टीवन दो अलग-अलग परियोजनाओं की सलाह देता है: WebAPI में DependencyResolver.SetResolver और HttpConfiguration.D dependencyResolver के बीच अंतर क्या है

Answer 5

मैंने हाल ही में लगभग एक ही काम किया है: मैंने वीएस2012 में वेब एपीआई टेम्पलेट का चयन करते हुए एक नए एमवीसी 4 वेब एप्लिकेशन प्रोजेक्ट के साथ शुरुआत की।

यह MVC के रूप में एक ही एप्लिकेशन में होस्ट किया गया एक वेब एपीआई बनाएगा।

मैं ApiControllers को एक अलग क्लास लाइब्रेरी प्रोजेक्ट में स्थानांतरित करना चाहता था। यह काफी आसान था लेकिन समाधान थोड़ा छिपा हुआ था।

विधानसभा में MVC 4 परियोजना के कोड में इसी तरह की कोड की एक पंक्ति है

[assembly: PreApplicationStartMethod(typeof(LibraryRegistrator), "Register")]

अब आपको क्लास लाइब्रेरीग्रैजिस्टेटर की जरूरत है (जो भी हो इसे बेझिझक नाम दें)

public class LibraryRegistrator
    {
        public static void Register()
        {
            BuildManager.AddReferencedAssembly(Assembly.LoadFrom(HostingEnvironment.MapPath("~/bin/yourown.dll")));
        }
    }

एमवीसी 4 परियोजना में आपी पुस्तकालय का संदर्भ भी है।

अब आप Api नियंत्रकों को अपने अलग वर्ग के पुस्तकालय (yourown.dll) में जोड़ सकते हैं।

Answer 6

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

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

Comments

अलग-अलग प्रोजेक्ट्स के लिए मेरा मुख्य तर्क यह है कि एपीआई वास्तव में फ्रंट एंड नहीं है। यह मध्यम श्रेणी का है।

— lordcheeto

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

— डैन बेचर

Answer 7

सेटअप के अलावा Web.Api के लिए अलग DLL।

केवल एक सलाह:

1. प्रोजेक्ट बनाएं
2. नगेट WebActivatorEx

3. App_start पर बुलाए जाने के लिए एक वर्ग विधि बनाएँ

   [विधानसभा: WebActivatorEx.PostApplicationStartMethod (typeof (API.AppWebActivator), "प्रारंभ")]

   [असेंबली: WebActivatorEx.ApplicationShutdownMethod (typeof (API.AppWebActivator), "शटडाउन")]

4. प्रारंभ विधि के अंदर एक web.api मार्गों को पंजीकृत करें

   सार्वजनिक स्थैतिक शून्य प्रारंभ () {GlobalConfiguration.Configure (WebApiConfig.Register); }

5. प्रोजेक्ट को वेब प्रोजेक्ट का संदर्भ दें। प्रारंभ विधि को सक्रिय करने के लिए।

उम्मीद है की यह मदद करेगा।

Answer 8

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

WebAPI कॉन्फ़िगरेशन MVC प्रोजेक्ट में ही छोड़ दिया जाता है। यह बढ़िया काम करता है।