👨🏾‍🍳 🦆 🐅 किसी भी असंगत स्थिति में - स्क्रिप्ट लिखें 🙌🏾 ☦️ 👨‍👧‍👦

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

कुछ परिचयात्मक शब्द

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

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

उन तकनीकों, जिन पर बाद में चर्चा की जाएगी, उन दोनों डेवलपर्स के लिए उपयोगी हो सकती हैं जो पहले से ही अपने आवेदन में स्क्रिप्ट का उपयोग करते हैं, और उन लोगों के लिए जो इसके बारे में सिर्फ सोच रहे हैं।

व्यक्तिगत कुछ भी नहीं, सिर्फ स्क्रिप्टिंग

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

Map<String, Object> parameters = createParametersMap(); ScriptEngineManager manager = new ScriptEngineManager(); ScriptEngine scriptEngine = manager.getEngineByName("groovy"); Object result = scriptEngine.eval(script.getScriptAsString("discount.groovy"), new SimpleBindings(parameters));

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

 public BigDecimal applyCustomerDiscount(Customer customer, BigDecimal orderAmount) { Map<String, Object> params = new HashMap<>(); params.put("cust", customer); params.put("amount", orderAmount); return (BigDecimal)scripting.evalGroovy(getScriptSrc("discount.groovy"), params); }

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

हम स्क्रिप्ट को पंप करते हैं

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

उदाहरण के लिए, सीयूबीए में एक सहज ज्ञान युक्त पटकथा इंजन बनाया गया था जो अतिरिक्त सुविधाओं का समर्थन करता है, जैसे:

जावा और ग्रूवी में स्क्रिप्ट लिखने की क्षमता
लिपियों को फिर से जोड़ने के लिए क्लास कैश नहीं
JMX बिन इंजन को नियंत्रित करने के लिए

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

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

स्प्रिंग फ्रेमवर्क: एक प्रस्ताव जो मना करना मुश्किल है?

स्प्रिंग में JDK एपीआई के शीर्ष पर निर्मित स्क्रिप्ट निष्पादन समर्थन है। org.springframework.scripting.* पैकेज में, आप कई उपयोगी कक्षाएं पा सकते हैं - ताकि आप आसानी से अपने आवेदन में स्क्रिप्टिंग के लिए निम्न-स्तरीय एपीआई का उपयोग कर सकें।

इसके अलावा, समर्थन का एक उच्च स्तर है, यह प्रलेखन में विस्तार से वर्णित है। संक्षेप में - आपको एक स्क्रिप्टिंग भाषा में एक कक्षा बनाने की आवश्यकता है (उदाहरण के लिए, ग्रूवी) और इसे एक XML विवरण के माध्यम से बीन के रूप में प्रकाशित करें:

 <lang:groovy id="messenger" script-source="classpath:Messenger.groovy"> <lang:property name="message" value="I Can Do The Frug" /> </lang:groovy>

एक बार एक बीन प्रकाशित होने के बाद, इसे IoC का उपयोग करके अपनी कक्षाओं में जोड़ा जा सकता है। स्प्रिंग फ़ाइल में पाठ बदलते समय स्क्रिप्ट का स्वत: अद्यतन प्रदान करता है, आप विधियों पर पहलुओं को लटका सकते हैं, आदि।

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

लिपियाँ: कठिनाइयाँ और विचार

तो, प्रत्येक समाधान की अपनी कीमत है, और अगर हम जावा अनुप्रयोगों में स्क्रिप्ट के बारे में बात करते हैं, तो इस तकनीक को शुरू करते समय, किसी को कुछ समस्याओं का सामना करना पड़ सकता है:

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

ऐसा लगता है कि जावा विधियों में स्क्रिप्ट कॉल को लपेटने से उपरोक्त समस्याओं को हल करने में मदद मिलेगी। यह बहुत अच्छा है अगर कुछ उपयोगिता वर्ग से eval(“disc_10_cl.groovy”) को कॉल करने के बजाय ऐसी कक्षाओं को IoC कंटेनर में प्रकाशित किया जा सकता है और उनकी सेवाओं में सामान्य, सार्थक नामों के साथ कॉल विधियां प्रकाशित की जा सकती हैं। एक और प्लस यह है कि कोड स्व-दस्तावेजीकरण हो जाता है, डेवलपर को इस बात की पहेली बनाने की जरूरत नहीं है कि फाइल नाम के पीछे किस तरह का एल्गोरिदम छिपा है।

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

परीक्षण को सरलीकृत किया जाता है - यह परिचित ढाँचों, मोक्स और बहुत कुछ का उपयोग करके "सामान्य" वर्ग परीक्षण में बदल जाता है।

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

स्क्रिप्ट रिपॉजिटरी - अवधारणा

विचार काफी सरल है और उन लोगों से परिचित होना चाहिए जो कम से कम एक बार वसंत के साथ काम करते हैं, खासकर वसंत जेपीए के साथ। आपको जावा इंटरफ़ेस बनाने और इसकी विधियों को कॉल करते समय स्क्रिप्ट को कॉल करने की आवश्यकता है। JPA में, एक समान दृष्टिकोण का उपयोग किया जाता है - CrudRepository पर कॉल को इंटरसेप्ट किया जाता है, विधि नाम और मापदंडों के आधार पर, एक अनुरोध बनाया जाता है, जिसे तब डेटाबेस इंजन द्वारा निष्पादित किया जाता है।

अवधारणा को लागू करने के लिए क्या आवश्यक है?

सबसे पहले, एक क्लास स्तर एनोटेशन ताकि आप इंटरफ़ेस को ढूंढ सकें - रिपॉजिटरी और इसके आधार पर एक बिन बना सकते हैं।

इसके अलावा, इस इंटरफेस के तरीकों पर एनोटेशन संभवत: विधि को कॉल करने के लिए आवश्यक मेटाडेटा को स्टोर करने के लिए काम में आएगा। उदाहरण के लिए - स्क्रिप्ट पाठ कहाँ से प्राप्त करें और किस इंजन का उपयोग करें।

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

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

 @ScriptRepository public interface PricingRepository { @ScriptMethod default BigDecimal applyCustomerDiscount(Customer customer, BigDecimal orderAmount) { return orderAmount.multiply(new BigDecimal("0.9")); } }

और फिर एल्गोरिथ्म ही, लिखित, उदाहरण के लिए, ग्रूवी में, समय पर पहुंच जाएगा, वहां छूट थोड़ी अलग होगी:

 def age = 50 if ((Calendar.YEAR - customer.birthday.year) >= age) { return orderAmount.multiply(0.75) } else { return orderAmount.multiply(0.9) }

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

 @Service public class CustomerServiceBean implements CustomerService { @Inject private PricingRepository pricingRepository; //Other injected beans here @Override public BigDecimal applyCustomerDiscount(Customer cust, BigDecimal orderAmnt) { if (customer.isRegistered()) { return pricingRepository.applyCustomerDiscount(cust, orderAmnt); } else { return orderAmnt; } //Other service methods here }

चुनौती पठनीय, समझने योग्य है और इसे बनाने के लिए व्यक्ति को किसी विशेष कौशल की आवश्यकता नहीं है।

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

यह कैसे काम करता है

@ScriptRepository के साथ चिह्नित सभी इंटरफ़ेसों के लिए, प्रॉक्सी ऑब्जेक्ट्स को प्रॉक्सी संदर्भ की Proxy क्लास की newProxyInstance पद्धति का उपयोग करके स्प्रिंग संदर्भ के प्रारंभ के दौरान बनाया जाता है। ये परदे के पीछे वसंत संदर्भ में सिंगलटन बीन्स के रूप में प्रकाशित होते हैं, इसलिए आप इंटरफ़ेस प्रकार के साथ एक वर्ग क्षेत्र की घोषणा कर सकते हैं और उस पर @Autowired या @Inject एनोटेशन डाल सकते हैं। बिल्कुल नियोजित।

स्क्रिप्ट इंटरफेस की स्कैनिंग और प्रसंस्करण @EnableSriptRepositories एनोटेशन का उपयोग करके सक्रिय किया जाता है, जैसे स्प्रिंग, JPA या MongoDB के लिए रिपॉजिटरी क्रमशः सक्रिय किए जाते हैं ( @EnableJpaRepositories और @EnableMongoRepositories ।)। एनोटेशन मापदंडों के रूप में, आपको उन पैकेजों के नाम के साथ एक सरणी निर्दिष्ट करना होगा जिसे आप स्कैन करना चाहते हैं।

 @Configuration @EnableScriptRepositories(basePackages = {"com.example", "com.sample"}) public class CoreConfig { //More configuration here. }

स्क्रिप्ट को कॉल करने के लिए मेटाडेटा जोड़ने के लिए तरीकों को @ScriptMethod साथ एनोटेट किया जाना चाहिए (इसी विशेषज्ञता के साथ @GroovyScript और @JavaScript भी है)। बेशक, इंटरफेस में डिफ़ॉल्ट तरीके समर्थित हैं।

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

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

प्रदाता और निष्पादक @ScriptMethod नाम @ScriptMethod एनोटेशन में निर्दिष्ट किए @ScriptMethod हैं, जहां आप विधि के निष्पादन समय पर एक सीमा भी निर्धारित कर सकते हैं। नीचे एक नमूना पुस्तकालय उपयोग कोड है:

 @ScriptRepository public interface PricingRepository { @ScriptMethod (providerBeanName = "resourceProvider", evaluatorBeanName = "groovyEvaluator", timeout = 100) default BigDecimal applyCustomerDiscount( @ScriptParam("cust") Customer customer, @ScriptParam("amount") BigDecimal orderAmount) { return orderAmount.multiply(new BigDecimal("0.9")); } }

आप @ScriptParam एनोटेशन को नोटिस कर सकते हैं - उन्हें स्क्रिप्ट में पास करते समय पैरामीटर नामों को इंगित करने की आवश्यकता होती है, क्योंकि जावा कंपाइलर स्रोतों से मूल नामों को मिटा देता है (ऐसा करने के तरीके नहीं हैं, लेकिन यह इस पर भरोसा नहीं करना बेहतर है)। आप पैरामीटर नामों को छोड़ सकते हैं, लेकिन इस मामले में, आपको स्क्रिप्ट में "arg0", "arg1" का उपयोग करना होगा, जो पठनीयता में सुधार नहीं करता है।

डिफ़ॉल्ट रूप से, लाइब्रेरी में रीडिंग के लिए प्रदाता होते हैं। डिस्क और संबंधित निष्पादकों से .groovy और .js फाइलें, जो कि मानक JSR-233 API पर रैपर हैं। आप विभिन्न स्क्रिप्ट स्रोतों के लिए और विभिन्न इंजनों के लिए अपनी खुद की सेम बना सकते हैं, इसके लिए आपको संबंधित इंटरफेस को लागू करने की आवश्यकता है: ScriptProvider और SpringEvaluator । पहला इंटरफ़ेस org.springframework.scripting.ScriptSource का उपयोग करता है और दूसरा org.springframework.scripting.ScriptEvaluator । स्प्रिंग एपीआई का उपयोग किया गया था ताकि यदि वे पहले से ही आवेदन में हैं तो तैयार कक्षाओं का उपयोग किया जा सके।
प्रदाता और कलाकार को अधिक लचीलेपन के लिए नाम से खोजा जाता है - आप अपने घटकों को समान नामों से नामित करके अपने आवेदन में पुस्तकालय से मानक बीन्स को बदल सकते हैं।

परीक्षण और संस्करण

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

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

कुल मिलाकर

प्रस्तुत पुस्तकालय स्प्रिंग एप्लिकेशन में स्क्रिप्ट को व्यवस्थित करने में मदद करेगा:

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

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

पुस्तकालय के स्रोत यहां हैं।

किसी भी असंगत स्थिति में - स्क्रिप्ट लिखें