मैं जावा / स्प्रिंग पर स्काला / लिफ्ट का उपयोग क्यों करूंगा? [बन्द है]

Question

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

Comments

प्रश्न बहुत पुराना है। लेकिन अब सवाल यह होगा कि "मुझे XYX पर स्काला / प्ले का उपयोग क्यों करना चाहिए" और कई अच्छे कारण हैं। मैं प्ले में चला गया और कभी पीछे मुड़कर नहीं देखा।

— जुस 12

Answer 1

मान लेते हैं कि हम स्काला और जावा में समान रूप से सहज हैं, और (विशाल) भाषा के अंतर को अनदेखा करते हैं, सिवाय इसके कि वे स्प्रिंग या लिफ्ट से संबंधित हैं।

स्प्रिंग और लिफ्ट परिपक्वता और लक्ष्यों के संदर्भ में लगभग विषम हैं।

• वसंत लिफ्ट से लगभग पांच साल बड़ा है
• लिफ्ट अखंड है और केवल वेब को लक्षित करता है; स्प्रिंग मॉड्यूलर है और दोनों वेब और "नियमित" ऐप को लक्षित करता है
• स्प्रिंग जावा ईई सुविधाओं की अधिकता का समर्थन करता है; लिफ्ट उस सामान की अनदेखी करती है

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

यहाँ ठोस अंतर हैं जो दोनों रूपरेखाओं के साथ काम करने के बाद मेरे दिमाग में अटक गए हैं। यह एक संपूर्ण सूची नहीं है, जिसे मैं किसी भी तरह संकलित नहीं कर सकता। बस मुझे जो सबसे दिलचस्प लगा ...

1. दर्शन देखें

   लिफ्ट स्निपेट / एक्शन विधियों में कुछ दृश्य सामग्री रखने के लिए प्रोत्साहित करती है। स्निपेट कोड विशेष रूप से प्रोग्राम उत्पन्न तत्वों, <div>एस, <p>एस, आदि के साथ छिड़का जाएगा ।

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

   इसके विपरीत, वेब के लिए स्प्रिंग का नियमित उपयोग दृश्य और बाकी चीजों के बीच एक मजबूत अलगाव को लागू करता है। मुझे लगता है कि स्प्रिंग कई टेम्प्लेटिंग इंजनों का समर्थन करता है, लेकिन मैंने केवल JSP का उपयोग कुछ गंभीर में किया है। JSP के साथ एक लिफ्ट-प्रेरित "फजी एमवीसी" डिजाइन करना पागलपन होगा। यह बड़ी परियोजनाओं पर एक अच्छी बात है, जहां सिर्फ पढ़ने और समझने का समय भारी हो सकता है।

2. ऑब्जेक्ट-रिलेशनल मैपर विकल्प

   लिफ्ट की निर्मित ORM "मैपर" है। "रिकॉर्ड" नामक एक आगामी विकल्प है, लेकिन मुझे लगता है कि यह अभी भी पूर्व-अल्फा माना जाता है। लैफ्टवेब बुक में मैपर और जेपीए दोनों का उपयोग करने पर अनुभाग हैं।

   लिफ्ट के CRUDify फ़ीचर, यह जितना अच्छा है, केवल मैपर (और न ही जेपीए) के साथ काम करता है।

   बेशक, स्प्रिंग मानक और / या परिपक्व डेटाबेस प्रौद्योगिकियों के एक विशाल समर्थन का समर्थन करता है । ऑपरेटिव शब्द "सपोर्ट" है। सैद्धांतिक रूप से, आप लिफ्ट के साथ किसी भी जावा ओआरएम का उपयोग कर सकते हैं, क्योंकि आप स्काला से मनमाने ढंग से जावा कोड कह सकते हैं। लेकिन लिफ्ट केवल वास्तव में मैपर का समर्थन करती है और (काफी हद तक) जेपीए। इसके अलावा, स्काला में nontrivial Java कोड के साथ काम करना वर्तमान में उतना सहज नहीं है जितना कि कोई पसंद कर सकता है; जावा ओआरएम का उपयोग करते हुए, आप संभवतः स्वयं को या तो जावा और स्काला संग्रह दोनों का उपयोग करके या सभी घटकों को जावा घटकों के अंदर और बाहर परिवर्तित करने के लिए पाएंगे।

3. विन्यास

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

   विन्यास की दृष्टि से वसंत काफी लचीला है। बहुत सारे कॉन्फिडेंस ऑप्शन को XML कॉन्फ़िगरेशन या एनोटेशन के जरिए चलाया जा सकता है।

4. प्रलेखन

   लिफ्ट का प्रलेखन युवा है। स्प्रिंग के डॉक्स बहुत परिपक्व हैं। कोई प्रतियोगिता नहीं है।

   चूंकि स्प्रिंग के डॉक्स पहले से ही अच्छी तरह से व्यवस्थित और खोजने में आसान हैं, इसलिए मैं उन डॉक्स की समीक्षा करूंगा जिन्हें मैंने लिफ्ट के लिए पाया था। मूल रूप से लिफ़्ट के दस्तावेज़ के 4 स्रोत हैं: LiftWeb Book , API डॉक्स , LiftWeb का Google समूह , और " गेटिंग स्टार्ट "। कोड उदाहरणों का एक अच्छा सूट भी है, लेकिन मैं उन्हें प्रति "प्रलेखन" नहीं कहूंगा।

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

   लेकिन लिफ्ट में उदाहरणों का एक अच्छा सेट है। यदि आप लिफ्ट कोड और उदाहरण कोड पढ़ने में सहज हैं (और आप पहले से ही स्काला को अच्छी तरह से जानते हैं), तो आप चीजों को काफी कम क्रम में काम कर सकते हैं।

दोनों चौखटे मजबूर कर रहे हैं। वहाँ क्षुधा की एक विस्तृत श्रृंखला है जहाँ आप या तो चुन सकते हैं और अच्छी तरह से कर सकते हैं।

Comments

एक अच्छा जवाब, एक बिंदु पर मैं असहमत हूँ: स्प्रिंग हैवीवेट है। यह अच्छी APIS की एक विस्तृत श्रृंखला है, और इसके लिए एक अच्छा परिणाम प्राप्त करने के लिए आवश्यक काम करने के कुछ संरचनात्मक तरीके लागू करता है, लेकिन J2EE सामान की तुलना में यह मूल रूप से बदल गया यह एक बहुत अधिक हल्के समाधान है। बेशक "हल्केपन" देखने वाले की आंखों में हैं, इसलिए यह निश्चित रूप से एक व्यक्तिपरक तर्क है। बस मेरे 2 सेंट तो।

— ब्रायन

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

— सवा 11

मैं लिफ्ट से उतना परिचित नहीं हूं जितना मैं होना चाहूंगा। आपकी राय में बूट ऑब्जेक्ट के लिए एक रैपर बनाना कितना मुश्किल होगा जो इसके बजाय एक xml फ़ाइल से सेटिंग्स पढ़ता है? मेरी पहली धारणा यह है कि चूंकि scala xml को इतनी अच्छी तरह से संभालता है, इसलिए यह असाधारण रूप से कठिन नहीं होगा।

— एपे-इनोगो

Sawyer, तथ्य यह है कि आप HTML को scala कोड में मिला सकते हैं यह नहीं कहता है कि आपके पास है। स्मार्ट तरीके से स्निपेट्स का उपयोग करने से HTML और स्काला कोड अलग हो जाएंगे। लेकिन हे, अपने नियंत्रण टैग का उपयोग जारी रखें;)

— एलेबन

@ क्या, क्या अब कोई अपडेट है कि लिफ्ट दोगुनी पुरानी है, जब आपने पहली बार यह लिखा था?

— पचेरियर

Answer 2

मुझे यह कहना चाहिए कि मैं डैन लारोक के जवाब से बहुत असहमत हूं।

लिफ्ट अखंड नहीं है। यह असतत तत्वों पर बना है। यह J / EE तत्वों की उपेक्षा नहीं करता है, यह JNDI, JTA, JPA, आदि की पसंद का समर्थन करता है। यह तथ्य कि आप J / EE के इन तत्वों का उपयोग करने के लिए मजबूर नहीं हैं, लिफ्ट के मॉड्यूलर डिजाइन का एक मजबूत संकेत है।

• लिफ्ट का दर्शन दर्शन "डेवलपर को निर्णय लेने दें।" लिफ्ट एक टेम्प्लेटिंग तंत्र प्रदान करता है जो दृश्य में किसी भी तर्क कोड, स्कैला कोड को निष्पादित करने के आधार पर एक दृश्य तंत्र और स्काला के XML शाब्दिक और स्कैलेट पर आधारित एक दृश्य तंत्र की अनुमति नहीं देता है । यदि आप XML टेम्प्लेटिंग तंत्र चुनते हैं, तो आप चुनते हैं कि आपके व्यवसाय तर्क में कितना, यदि कोई है, तो मार्क-अप होता है। लिफ्ट के दृश्य पृथक्करण को स्प्रिंग की पेशकश की तुलना में कुछ भी मजबूत नहीं है क्योंकि आप लिफ्ट के XML टेम्प्लेट में किसी भी व्यावसायिक तर्क को व्यक्त नहीं कर सकते हैं।
• लिफ्ट की वस्तु Object दृढ़ता दर्शन "डेवलपर को निर्णय लेने दें।" लिफ़्ट में मैपर है जो एक ActiveRecord स्टाइल ऑब्जेक्ट रिलेशनल मैपर है। इसे छोटे प्रोजेक्ट्स के लिए काम मिलता है। लिफ्ट का समर्थन जेपीए। Lift में एक रिकॉर्ड एब्स्ट्रैक्शन होता है, जो NoSQL स्टोर्स में और बाहर रिलेशनल डेटाबेस में वस्तुओं को बंद करने का समर्थन करता है, (Lift में CouchDB और MongoDB के लिए मूल समर्थन शामिल है, लेकिन एडेप्टर लेयर्स कोड की कुछ सौ लाइनें हैं, इसलिए यदि आप कैसेंड्रा चाहते हैं या कुछ और, इसे पाने के लिए बहुत काम नहीं है।) मूल रूप से, वेब फ्रेमवर्क को लिफ्ट करना इस बात पर निर्भर नहीं है कि वस्तुओं को एक सत्र में कैसे व्यवस्थित किया जाता है। इसके अलावा, सत्र और अनुरोध चक्र ऐसे खुले हैं जो अनुरोध / प्रतिक्रिया चक्र में लेनदेन हुक सम्मिलित करना सरल है।
• लिफ्ट का दर्शन है "सर्वर टीम को एक भाषा को जानने की जरूरत है, न कि कई भाषाओं को।" इसका अर्थ है कि विन्यास स्काला के माध्यम से किया जाता है। इसका मतलब है कि हमें लचीले विन्यास विकल्प बनाने के लिए 40% जावा भाषा के निर्माणों को XML सिंटैक्स में लागू नहीं करना था। इसका मतलब है कि कंपाइलर सिंटैक्स और कॉन्फ़िगरेशन डेटा टाइप करता है ताकि आपको रनटाइम के दौरान कोई अजीब XML पार्सिंग या गलत डेटा न मिले। इसका मतलब यह है कि आपके पास आईडीई नहीं है जो उस एनोटेशन के विवरण को समझते हैं जो आप उस लाइब्रेरी के आधार पर उपयोग कर रहे हैं जिसका आप उपयोग कर रहे हैं।
• हां, लिफ्ट का प्रलेखन इसका मजबूत बिंदु नहीं है।

ऊपर कहा जा रहा है, मुझे लिफ्ट के डिजाइन दर्शन के बारे में कुछ बात करने दें।

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

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

ajaxButton("Accept", () => {request.accept.save; 
                            SetHtml("acceptrejectspan", <span/>}) ++ 
ajaxButton("Reject", () => {request.reject.save; 
                            SetHtml("acceptrejectspan", <span/>})

यह इत्ना आसान है। क्योंकि फंक्शन क्रिएट होने पर FriendRequest स्कोप में होता है, फंक्शन स्कोप के ऊपर बंद हो जाता है ... फ्रेंड रिक्वेस्ट की प्राइमरी की को एक्सपोज करने या कुछ और करने की जरूरत नहीं है ... बस बटन के टेक्स्ट को डिफाइन करें (यह स्थानीयकृत किया जा सकता है या इसे XHTML टेम्पलेट से खींचा जा सकता है या इसे स्थानीय टेम्पलेट से खींचा जा सकता है) और बटन को धकेलने पर कार्य करने के लिए फ़ंक्शन। लिफ्ट ने GUID को असाइन करने, अजाक्स कॉल (jQuery या YUI के माध्यम से स्थापित करने, और हाँ, आप अपने पसंदीदा जावास्क्रिप्ट पुस्तकालय जोड़ सकते हैं) का ध्यान रखते हैं, बैक-ऑफ़ के साथ स्वचालित रिट्रीज़ कर रहे हैं, अजाक्स अनुरोधों की कतार से कनेक्शन भुखमरी से बचते हैं, आदि।

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

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

  serve {
    case "api" :: "user" :: AsUser(user) :: _ XmlGet _ => <b>{user.name}</b>
    case "api" :: "user" :: AsUser(user) :: _ JsonGet _ => JStr(user.name)
  }

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

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

@Foursquare के लिए चार सितारे - थोड़ी देर में पहली साइट पर मैंने एक अच्छी तरह से देखा है कि एक भी सुरक्षा मुद्दा नहीं है (जो मुझे मिल सकता है) - http://twitter.com/rasmus/status/5929904263

उस समय, FourSquare में एक इंजीनियर था जो कोड पर काम कर रहा था (यह नहीं कि @harryh एक सुपर-जीनियस नहीं है) और उसका मुख्य ध्यान साप्ताहिक ट्रैफ़िक दोहरीकरण के साथ मुकाबला करते हुए FourSquare के PHP संस्करण को फिर से लिखना था।

Lift के सुरक्षा फ़ोकस का अंतिम भाग SiteMap है। यह एक एकीकृत अभिगम नियंत्रण, साइट नेविगेशन और मेनू प्रणाली है। डेवलपर Scala कोड (जैसे If(User.loggedIn _)या If(User.superUser _)) का उपयोग करके प्रत्येक पृष्ठ के लिए एक्सेस कंट्रोल नियमों को परिभाषित करता है और किसी भी पेज रेंडरिंग शुरू होने से पहले उन एक्सेस कंट्रोल नियमों को लागू किया जाता है। यह स्प्रिंग सिक्योरिटी की तरह है, सिवाय इसके कि यह प्रोजेक्ट की शुरुआत से बेक किया गया है और एक्सेस कंट्रोल रूल्स बाकी एप्लिकेशन के साथ एकीकृत हैं, इसलिए URL के समय आपको एक्सएमएल में सुरक्षा नियमों को अपडेट करने की प्रक्रिया नहीं करनी होगी। परिवर्तन या पहुंच नियंत्रण की गणना करने वाले तरीके।

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

लेकिन लिफ्ट आपको आसपास किसी भी वेब फ्रेमवर्क का सबसे अच्छा धूमकेतु समर्थन भी देती है। इसीलिए नोवेल ने अपने पल्स प्रोडक्ट को पावर देने के लिए लिफ्ट को चुना और यहाँ पर नोवेल का क्या कहना है लिफ्ट के बारे में:

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

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

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

Comments

Blog.lostlake.org/index.php?/archives/16-Web-Framework-Manifesto.html का संग्रहीत संस्करण में उपलब्ध है replay.web.archive.org/20070220231839/http://blog.lostlake.org/...

— एलन हेचट

आपने मुझे MongoDB मूल समर्थन पर ... I

— इनरन मेडन

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

— टोनी के।

@TonyK .: निश्चित रूप से स्प्रिंग भारी है, लेकिन अगर वेब-ऐप को बाद में बदल दिया जाता है, तो यह भुगतान-बंद हो जाएगा, क्योंकि स्प्रिंग के साथ रिफैक्टर / विस्तार करना बहुत आसान है। IMHO, यह निर्भर करता है। मैंने कुछ अन्य फ्रेमवर्क का उपयोग किया है, जैसे कि ग्रेल्स, छोटी परियोजनाओं पर और मुझे लगता है कि यह इसके लिए पूरी तरह से है - लेकिन कुछ के लिए बहुत बाद में बदलाव होगा, मैं स्प्रिंग के साथ जाऊंगा।

— लॉन्ग

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

— टोनी के।

Answer 3

मैं आपको प्ले फ्रेमवर्क की जांच करने की सलाह दूंगा, इसमें कुछ बहुत ही दिलचस्प विचार हैं और जावा और स्काला में विकास का समर्थन करता है

Comments

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

— टोनी के।

Answer 4

सिर्फ मनोरंजन के लिए। और नए प्रोग्रामिंग दृष्टिकोण सीखने के लिए।

Answer 5

मैंने हाल ही में एक वेब परियोजना के लिए लिफ्ट का उपयोग करने पर जोर दिया, जो स्प्रिंग एमवीसी का बहुत बड़ा प्रशंसक नहीं था। मैंने नवीनतम संस्करणों का उपयोग नहीं किया है, लेकिन स्प्रिंग एमवीसी के पुराने संस्करणों ने आपको वेब एप्लिकेशन चलाने के लिए बहुत सारे हुप्स के माध्यम से कूद दिया। मैं लिफ्ट पर लगभग बेच दिया गया था जब तक मैंने देखा कि लिफ्ट बहुत सत्र निर्भर हो सकती है और सही ढंग से काम करने के लिए 'चिपचिपा सत्र' की आवश्यकता होगी। Http://exploring.liftweb.net/master/index-9.html#sec:Session-Management से अंश

जब तक एक मानक सत्र प्रतिकृति तकनीक है तब भी आप "चिपचिपा सत्र" का उपयोग करके आवेदन को बंद कर सकते हैं। यह सेशन जो HTTP सत्र से संबंधित सभी अनुरोधों को समान क्लस्टर नोड द्वारा संसाधित किया जाना चाहिए

एक बार एक सत्र की आवश्यकता होती है, तो उपयोगकर्ता को उस नोड पर पिन करना होगा। यह बुद्धिमान लोड संतुलन की आवश्यकता पैदा करता है और स्केलिंग को प्रभावित करता है, जिसने लिफ्ट को मेरे मामले में समाधान होने से रोक दिया। मैंने http://www.playframework.org/ का चयन किया और बहुत प्रसन्न हुआ। प्ले अब तक स्थिर और विश्वसनीय रहा है और इसके साथ काम करना बहुत आसान है।

Answer 6

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

Answer 7

अपने ज्ञान का विस्तार हमेशा एक सार्थक प्रयास है :) मैंने अभी स्काला सीखना शुरू किया है, यह प्रभावित कर रहा है कि मैं सामान्य जावा कैसे लिखता हूं और मैं कह सकता हूं कि यह अब तक बहुत फायदेमंद रहा है।

Answer 8

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

Answer 9

मेरी विनम्र राय में, कल्पना क्या मायने रखती है।

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

Real app = programming language (imagined app)

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

मेरे लिए, मैं धीरे-धीरे स्काला और लिफ्ट सीख रहा हूं और इसे प्यार कर रहा हूं।

Answer 10

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