बड़े AngularJS और जावास्क्रिप्ट अनुप्रयोगों में कोड संगठन

अनुवादक से: मुझे लगता है कि प्रारंभिक स्तर पर एप्लिकेशन आर्किटेक्चर और कोड संगठन के लेख सबसे महत्वपूर्ण हैं, क्योंकि, बाकी सभी चीजों के विपरीत, एप्लिकेशन के आधार को बदलना बहुत मुश्किल है। [ मूल लेख ]

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

सामान्य प्रवृत्ति प्रकार द्वारा संस्थाओं के आयोजन के साथ एक जुनून है। वह हड़ताली के समान है कि लोग अपने कपड़े कैसे छाँटते हैं।

फर्श पर ढेर

आइए, आपके एप्लिकेशन बनाने के लिए आधिकारिक प्रारंभिक बिंदु, कोणीय टेम्पलेट प्रोजेक्ट पर एक नज़र डालें। एप्लिकेशन निर्देशिका में निम्न संरचना है:

• सीएसएस /
• img /
• js /
  
  • app.js
  • controllers.js
  • directives.js
  • filters.js
  • services.js
• देय /
• भाग्यांक /

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

यह एक गड़बड़ है। लोगों को इस तरह नहीं रहना चाहिए, और डेवलपर्स को ऐसे कोड का समर्थन नहीं करना चाहिए। जैसे ही आपके नियंत्रकों और सेवाओं की संख्या दस से अधिक हो जाती है, फ़ाइल संरचना बहुत बोझिल हो जाएगी: ऑब्जेक्ट खोजना मुश्किल हो जाएगा, नियंत्रण के स्रोत में परिवर्तन की फ़ाइल अपारदर्शी हो जाती है, आदि।

सॉक बॉक्स

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

आइए कल्पना करें कि हम एक सरल ई-कॉमर्स साइट लॉगिन फॉर्म, उत्पाद सूची और खरीदारी कार्ट इंटरफ़ेस के साथ बना रहे हैं। हमने मॉडल (व्यावसायिक तर्क और राज्य) और सेवाओं (HTTP / JSON टर्मिनलों के लिए परदे के पीछे) के लिए नई संस्थाओं को परिभाषित किया, और उन्हें "सेवाओं" के एक ढेर में नहीं डंप किया। हमारी जावास्क्रिप्ट निर्देशिका इस तरह दिखाई देगी:

• नियंत्रक /
  • LoginController.js
  • RegistrationController.js
  • ProductDetailController.js
  • SearchResultsController.js
• directives.js
• filters.js
• मॉडल /
  • CartModel.js
  • ProductModel.js
  • SearchResultsModel.js
  • UserModel.js
• सेवाएं /
  • CartService.js
  • UserService.js
  • ProductService.js

बहुत बढ़िया! वस्तुओं को अब बाहर रखा जाता है ताकि फ़ाइल की पेड़ को देखने या गर्म कुंजियों का उपयोग करके इसके माध्यम से नेविगेट करना आसान हो; परिवर्तनों की सूची में यह इंगित करना आसान है कि क्या परिवर्तन किए गए थे, आदि। यह प्रमुख सुधारों में से एक है, लेकिन अभी भी कुछ सीमाएं हैं।

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

क्या यह बुरा नहीं होगा यदि आपके कपड़े तुरंत एक साथ एक पोशाक में डाल दिए गए थे? हालांकि व्यवहार में लागत और स्थान के रूप में ऐसे प्रतिबंध हैं जो आपको वास्तविक दुनिया में कपड़े के साथ ऐसा करने से रोकते हैं, आप कोड के साथ कुछ ऐसा ही कर सकते हैं बिल्कुल मुफ्त।

प्रतिरूपकता

चलो उम्मीद करते हैं कि केले के रूपक बहुत थकाऊ नहीं थे, और यहाँ सारांश है:

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

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

• गाड़ी /
  
  • CartModel.js
  • CartService.js
• सामान्य /
  
  • directives.js
  • filters.js
• उत्पाद /
  
  • खोज /
    
    • SearchResultsController.js
    • SearchResultsModel.js
  • ProductDetailController.js
  • ProductModel.js
  • ProductService.js
• उपयोगकर्ता /
  
  • LoginController.js
  • RegistrationController.js
  • UserModel.js
  • UserService.js

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

कोणीय में, हम इस कदम को एक आधार के रूप में ले सकते हैं और उपयुक्त कोड के साथ एक मॉड्यूल बना सकते हैं:

var userModule = angular.module('userModule',[]); userModule.factory('userService', ['$http', function($http) { return new UserService($http); }]); userModule.factory('userModel', ['userService', function(userService) { return new UserModel(userService); }]); userModule.controller('loginController', ['$scope', 'userModel', LoginController]); userModule.controller('registrationController', ['$scope', 'userModel', RegistrationController]); 

यदि आप तब उपयोगकर्ता फ़ोल्डर में UserModule.js डालते हैं, तो यह इस मॉड्यूल में प्रयुक्त "स्पष्ट" ऑब्जेक्ट बन जाता है। यह भी आवश्यक होगा कि आवश्यकताएँ या ब्राउज़र लोडर के लिए कुछ निर्देश जोड़ें।

सामान्य कोड टिप्स

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

1. यदि आपके मॉड्यूल की वस्तुओं को कई "सामान्य" वस्तुओं तक सीधी पहुंच की आवश्यकता होती है, तो उनके लिए एक या अधिक facades बनाएं। यह प्रत्येक वस्तु के लिए परजीवियों की संख्या को कम करने में मदद करेगा, क्योंकि एक नियम के रूप में, बहुत से परजीवी की उपस्थिति इंगित करती है कि कोड सड़ा हुआ है।
2. यदि आपका "सामान्य" फ़ोल्डर एक बड़ा मॉड्यूल बन जाता है, तो इसे विशिष्ट कार्यात्मक कार्यों या समस्याओं को हल करने के लिए सबमॉड्यूल में विभाजित करें। सुनिश्चित करें कि एप्लिकेशन मॉड्यूल केवल "जेनेरिक" मॉड्यूल का उपयोग करें जिनकी उन्हें आवश्यकता है। यह SOLID से " इंटरफ़ेस पृथक्करण का सिद्धांत " है।
3. उपयोगिता विधियों को $ rootScope में जोड़ें ताकि उनका उपयोग बाल क्षेत्रों में किया जा सके। यह आवेदन में प्रत्येक नियंत्रक में एक ही निर्भरता (उदाहरण के लिए, "अनुमतियाँमॉडल") को इंजेक्ट करने की आवश्यकता को समाप्त करता है। कृपया ध्यान दें कि वैश्विक दायरे में अव्यवस्था से बचने और निर्भरता को स्पष्ट नहीं करने के लिए यह सोच-समझकर किया जाना चाहिए।
4. अलग घटकों के लिए घटनाओं का उपयोग करें जिन्हें एक दूसरे के लिए स्पष्ट संदर्भ की आवश्यकता नहीं है। एंगुलर में, यह ऑब्जेक्ट के दायरे में $ emit , $ ब्रॉडकास्ट और तरीकों पर $ का उपयोग करके किया जाता है। नियंत्रक कुछ कार्यों को करने के लिए एक घटना उत्पन्न कर सकता है, और फिर एक अधिसूचना प्राप्त कर सकता है कि कार्रवाई पूरी हो गई है।

संसाधनों और परीक्षणों पर एक संक्षिप्त टिप्पणी

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