2013-07-01 8 views
9

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

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

मैं कैसे हमारे सर्वर और ग्राहक के बीच प्रतिबाधा बेमेल को कम किया जा सकता है के लिए विभिन्न विचारों लिया है। लेकिन कुछ भी जल्दी या आसान लगता है।

मैं के बारे में सोचा गया है: -

  1. एक नया बाकी सेवा लिखें। वास्तव में ग्राहक-पक्ष क्या चाहता है, लेकिन नए विकास का एक गंभीर टुकड़ा।
  2. WebHttp बाइंडिंग कुछ पेश करने लगती है। लेकिन मुझे लगता है यह कस्टम विशेषता के सी # मार्कअप की आवश्यकता की तरह (कैसे प्राप्त करने के लिए जब हमारे सी # डबल्यूएसडीएल से उत्पन्न होता है) और संभवतः हमारे जटिल प्रकार समर्थन नहीं करेंगे
  3. प्राप्त या अमूर्त दूर बुला सोप करने के लिए क्लाइंट साइड जे एस का भार बारे में सेवाएं। लेकिन, जब तक यह डब्लूएसडीएल से स्वत: जेनरेट नहीं किया जा सकता है, यह लिखने के लिए क्लाइंट-साइड कोड की एक बड़ी मात्रा है।
  4. सर्वर के लिए एक IDISpatchMessageFormatter लिखें, जो मैंने खोजे संदेशों के कुछ JSON प्रारूप को स्वीकार करने के लिए। मुश्किल लगता है, विशेष रूप से IDispatchMessageFormatter को कार्यान्वित करने और एकीकृत करने वाले लोगों के अच्छे उदाहरण आने के लिए मुश्किल लगते हैं।
  5. JSON और XML के बीच स्वैप करने के लिए एक संदेश एन्कोडर लिखें। लेकिन यह वास्तव में एक एन्कोडिंग ऑपरेशन नहीं है, क्योंकि जब मैंने इसे लिखने की कोशिश की तो बहुत स्पष्ट हो गया!

मैं सुझाव के लिए खोज कर रहा हूँ।

+0

कितने आपरेशन अनुबंध (विधि) अपने WCF सर्वर को उजागर करता है? क्या आप एक वेबएपीआई सर्वर लिख सकते हैं जो डब्ल्यूसीएफ सेवा कार्यान्वयन कक्षा (1 वेब विधि: 1 ऑपरेशन अनुबंध) को एम्बेड और कॉल करता है और जेसन के रूप में अस्थायी रूप से डेटा ऑब्जेक्ट्स को वापस लाता है (यानी यह ऑपरेशन अनुबंधों की संख्या और जटिलता को संभव है)? यह संभव होना चाहिए, हालांकि यदि आप अपने सेवा संचालन में बहुरूपता पर भरोसा करते हैं तो उनको JSON (AFAIK) में दोहराया नहीं जा सकता है। –

+0

सात सेवाएं हैं और कुल 50 ऑपरेशन हैं। – PeteAC

+0

एक बाकी सेवा लिखने के बारे में कैसे साबुन सेवा पर कॉल का प्रतिनिधि होगा? –

उत्तर

8

आम तौर पर, मैं किसी भी AngularJS विकास के लिए एक बाकी सेवा की सिफारिश और Node.js API सर्वर तंत्रों के एक नंबर लपेटा है। निस्संदेह "यह निर्भर करता है" की एक बड़ी राशि है, लेकिन आमतौर पर अधिकांश परियोजनाएं उस मार्ग के बाद अधिक खुश और अधिक उत्पादक होंगी।

कुछ चीजें बारे

  1. कितनी अच्छी तरह अपने वर्तमान सोप API यूजर इंटरफेस आवश्यकताओं फिट करता है लगता है कि करने के लिए?
  2. क्या आप एक्सप्रेस, सिनात्रा, फ्लास्क या अन्य सूक्ष्म ढांचे के साथ अनुभव कर रहे हैं जो आरईएसटी एपीआई के तेज़ी से विकास की अनुमति देते हैं? मुझे लगता है कि मैं कुछ घंटों में एक ठोस नोड.जेएस एक्सप्रेस एपीआई सर्वर का निर्माण कर सकता हूं और फिर इसे विस्तारित करता हूं क्योंकि मैं एंगुलरजेएस एप्लिकेशन का निर्माण करता हूं।
  3. आप AngularJS के साथ कितने अनुभवी हैं? यह एक जटिल डेटा परत क्लाइंट-साइड बनाने के लिए एक और अधिक उन्नत परियोजना है।

छह कारण बाकी AngularJS

  1. के लिए महत्वपूर्ण है यह $ संसाधन और $ http का उपयोग कर कोणीय कोड लिखने के लिए ज्यादा तीव्र है। प्रभावी एंगुलरजेएस विकास के लिए एपीआई अधिकार एक अच्छी सिफारिश है। वास्तव में, आप तर्क दे सकते हैं कि AngularJS को REST के लिए डिज़ाइन किया गया है, और यही कारण है कि सादे जावास्क्रिप्ट मॉडल के लिए काम करता है (देखें 2)।
  2. कोणीय का सादा पुराना जावास्क्रिप्ट ऑब्जेक्ट डेटा मॉडल एक आरईएसटी एपीआई के साथ अच्छी तरह से काम करता है जो जेएसओएन बोलता है जो यूजर इंटरफेस से मेल खाता है। हालांकि, जब कोई अच्छा फिट नहीं होता है तो समस्याएं उत्पन्न होती हैं- कोणीय में औपचारिक डेटा मॉडल नहीं होता है, इसलिए आप एंगुलर के साथ अच्छी तरह से काम करने के लिए अपने एपीआई को तर्कसंगत बनाने की कोशिश कर रहे बहुत सारे कोड लिखते हैं। Wind.js जैसे तृतीय पक्ष पुस्तकालय कुछ समाधान प्रदान कर सकते हैं, लेकिन यह अभी भी अजीब है।
  3. आप आसानी से कैशिंग के साथ स्केल कर सकते हैं। मिश्रण में रेडिस या मेमकेचे या वार्निश या अन्य सामान्य HTTP कैशिंग समाधान जोड़ना आसान है। आरईएसटी एपीआई की पारदर्शिता और निष्क्रियता के कारण संसाधन-आधारित अबास्ट्रक्शन कैशिंग रणनीतियों के लिए एकदम सही हैं।
  4. फ़्रंट एंड एंड सर्वर की लूज युग्मन - यदि आप एसओएपी को माइग्रेट करते हैं या अन्य सेवाओं के साथ एकीकृत करने की आवश्यकता है तो बैकएंड में बदलावों का समर्थन करना आसान होगा।
  5. एंजुलरजेएस तर्क से अलग जेएसओएन एपीआई का परीक्षण करना आम तौर पर आसान है, इसलिए आपके परीक्षण सूट सरल और अधिक प्रभावी होंगे।
  6. भविष्य में AngularJS और JSON- उन्मुख परियोजनाओं के लिए आपका नया REST API लाभ उठाना आसान होगा।

मुझे उम्मीद है कि इससे मदद मिलती है।

चीयर्स, निक

संबंधित मुद्दे