क्या angularjs के निर्देश को सीधे सेवाओं के साथ इंटरैक्ट करना चाहिए या इसे एक एंटी-पैटर्न माना जाता है?


35

कौन सा बेहतर माना जाता है:

  • एक निर्देश है कि सीधे सेवाओं के साथ बातचीत करता है

या

  • ऐसा निर्देश होना जो कुछ हुक को उजागर करता है कि कौन सा नियंत्रक व्यवहार (सेवाओं को शामिल) से बांध सकता है?

मुझे थोड़ा और संदर्भ की आवश्यकता होगी कि आप क्या हासिल करना चाहते हैं, क्या संप्रेषित है, कितना सोर्स कोड अपेक्षित है कि आपका डोमेन क्या है, इसे कैसे स्केल करना है?
उपयोगकर्ता

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

जवाबों:


24

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

  • विजेट के लिए डेटा के प्रदर्शन / प्रवेश के लिए यूआई को नियंत्रित करना।
  • बैकएंड पर सबमिट करना (सेवा के माध्यम से)।

लेकिन इसे कम पुन: प्रयोग करने योग्य भी बनाया जा सकता है, क्योंकि आप इसे फिर से किसी अन्य सेवा के साथ, या एक अलग यूआई के साथ (कम से कम आसानी से नहीं) कर सकते हैं।

ये निर्णय लेते समय , मैं अक्सर अंतर्निहित HTML तत्वों से तुलना करता हूं: उदाहरण के लिए <input>, <textarea>या <form>: वे किसी भी विशिष्ट बैकएंड से पूरी तरह से स्वतंत्र हैं। एचटीएमएल 5 ने <input>तत्व को कुछ अतिरिक्त प्रकार दिए हैं, उदाहरण के लिए date, जो अभी भी बैकएंड से स्वतंत्र है, और जहां वास्तव में डेटा जाता है या इसका उपयोग कैसे किया जाता है। वे विशुद्ध रूप से इंटरफ़ेस तत्व हैं। आपके कस्टम विजेट, निर्देशों का उपयोग करके बनाया गया है, मुझे लगता है कि यदि संभव हो तो उसी पैटर्न का पालन करना चाहिए।

हालाँकि, यह कहानी का अंत नहीं है। अंतर्निहित HTML तत्वों के साथ सादृश्य से परे, आप पुन: प्रयोज्य निर्देश बना सकते हैं जो दोनों कॉल सेवाओं, और विशुद्ध रूप से यूआई निर्देश का उपयोग करते हैं, जैसे यह एक का उपयोग कर सकता है <textarea>। आप निम्नानुसार कुछ HTML का उपयोग करना चाहते हैं:

<document document-url="'documents/3345.html'">
 <document-data></document-data>
 <comments></comments>
 <comment-entry></comment-entry>
</document>

commentEntryनिर्देश को कोड करने के लिए , आप एक बहुत छोटा निर्देश बना सकते हैं जिसमें बस नियंत्रक होता है जो एक यूआई-विजेट के साथ एक सेवा को जोड़ता है। कुछ इस तरह:

app.directive('commentEntry', function (myService) {
  return {
    restrict: 'E',
    template: '<comment-widget on-save="save(data)" on-cancel="cancel()"></comment-widget>',
    require: '^document',
    link: function (scope, iElement, iAttrs, documentController) {
      // Allow the controller here to access the document controller
      scope.documentController = documentController;
    },
    controller: function ($scope) {
      $scope.save = function (data) {
        // Assuming the document controller exposes a function "getUrl"
        var url = $scope.documentController.getUrl(); 

        myService.saveComments(url, data).then(function (result) {
          // Do something
        });
      };
    }
  };
});

इसे चरम पर ले जाने के लिए, आपको कभी भी ng-controllerHTML में एक मैनुअल विशेषता की आवश्यकता नहीं हो सकती है : आप इसे सभी निर्देशों का उपयोग करके कर सकते हैं, जब तक कि प्रत्येक में सीधे "UI" भूमिका या एक स्पष्ट "डेटा" भूमिका हो।

एक नकारात्मक पहलू है जिसका मुझे उल्लेख करना चाहिए: यह एप्लिकेशन को अधिक "चलती भागों" देता है, जो थोड़ा जटिलता जोड़ता है। हालांकि, यदि प्रत्येक भाग की स्पष्ट भूमिका है, और अच्छी तरह से (इकाई + E2E परीक्षण किया गया है), तो मैं तर्क करूंगा कि यह इसके लायक है और दीर्घकालिक में एक समग्र लाभ है।


59

मुझे मीकल चार्मेज़ा जवाब से असहमत होने दें।

यद्यपि उनका उत्तर सैद्धांतिक रूप से सही है, लेकिन वास्तविक दुनिया के लिए यह बहुत व्यावहारिक नहीं है।

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

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

इसके बजाय, आपको अपने ऐप के लिए एक डोमेन विशिष्ट भाषा (DSL) बनाने के निर्देशों का उपयोग करना चाहिए, जो अपने डोमेन पर रहता है।

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

लेकिन अगर आप एक लॉगिन बॉक्स की तरह कुछ बना रहे हैं जो आपके बैक-एंड को बांधता है, तो बस इसे करें।

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

इसे सरल रखें। :)


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

2

मुझे लगता है कि "एक निर्देश को एक सेवा के साथ बातचीत करनी चाहिए" सवाल इस बात पर निर्भर करता है कि आपकी सेवा क्या कर रही है।

मेरे पास ऐसे निर्देश हैं जो HTTP अनुरोधों के साथ कुछ भी नहीं करते हैं और मुझे लगता है कि यह एक अच्छा पैटर्न है। सेवाएँ / फ़ैक्टरियाँ अधिक डेटा उन्मुख लॉजिक को एन्कैप्सुलेट करने के लिए बहुत अच्छी हैं, और निर्देशन प्रेजेंटेशन ओरिएंटेड लॉजिक के लिए महान हैं। कोणीय डॉक्स में सेवाओं का घोषित उद्देश्य है: "आप अपने ऐप में कोड को व्यवस्थित और साझा करने के लिए सेवाओं का उपयोग कर सकते हैं।" यह बहुत व्यापक है, लेकिन सेवाओं का उपयोग निर्देशों में उस लक्ष्य को प्राप्त करने के लिए किया जा सकता है।

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


1

AngularJS ढांचे के अनुसार, हमें सर्वर से किसी भी डेटा को प्राप्त करने के लिए सिंगलटन कारखानों / सेवाओं को करना चाहिए। ताकि इन फैक्ट्रियों को एक ही दोबारा लिखे बिना आवेदन भर में पुन: उपयोग किया जा सके। सीधे निर्देश के अंदर हम इन फैक्ट्रियों को आपी / सर्वर से प्राप्त डेटा प्राप्त करने के लिए कॉल कर सकते हैं।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.