🙌🏼 🥜 🆗 सिम्फनी: कैसे शुरू करें 🚊 💰 ⛹️

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

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

खैर, मैं विचलित हूं। आज मैं इस बारे में बात करना चाहता हूं कि सिम्फनी का उपयोग करते हुए एक प्रणाली विकसित करते समय कहां से शुरू करना चाहिए और किन नियमों का पालन किया जाना चाहिए।

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

परियोजना

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

क्षुधा

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

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

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

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

वातावरण (वातावरण)

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

सामान्य तौर पर, शिकायत करने के लिए कुछ भी नहीं है - सब कुछ, मेरी राय में, बस सही है।

मॉड्यूल (मॉड्यूल)

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

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

आखिरी बात मैं इस पर ध्यान देना चाहूंगा ...

मॉडल (मॉडल)

सभी मॉडल एक (या कई) YAML फ़ाइलों में संग्रहीत हैं। आपको 3-4 दिनों में मॉडल लिखने की आदत हो जाती है। YAML से, एक कमांड वाला मॉडल स्वचालित रूप से जनरेट होने वाले आधार ORM क्लासेस ( प्रोपेल या डॉक्ट्रिन ) में परिवर्तित हो जाता है। सब कुछ तेज, सरल और साफ है।

शायद यह सब है कि सिम्फनी का अध्ययन करते समय एक शुरुआत की आवश्यकता हो सकती है (ताकि यह उसे किसी प्रकार की जटिल और समझ से बाहर की प्रणाली के लिए न लगे, जो मुझे एक साल पहले लगती थी)।

और अब हम अपनी सिफारिशों के लिए सीधे पास होंगे। लेकिन इससे पहले मैं आपको इसके बारे में बताऊंगा ...

प्लगइन्स (प्लगइन्स)

प्लगइन्स वास्तव में, कोड है जो विभिन्न परियोजनाओं और अनुप्रयोगों में कई बार उपयोग किया जा सकता है। प्लगइन्स शामिल हो सकते हैं:

विन्यास फाइल, उनके मॉडल सहित (!!!)
मॉड्यूल
पुस्तकालय

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

मेरी सिफारिशें

सबसे पहले - डिजाइन। इस कदम पर कंजूसी न करें, ग्राहक के साथ समझ से बाहर के बिंदुओं का विश्लेषण और स्पष्टीकरण करें।
आपके सामने देखना (हाँ, आपके दिमाग में भी) सिस्टम का लेआउट - सोचें कि सिस्टम के किन हिस्सों को विभाजित किया जा सकता है।
मौजूदा प्लगइन्स ( आवश्यक ) के बीच ऐसे भागों की तलाश करें। मैंने अपनी परियोजना में निम्नलिखित प्लगइन्स का उपयोग किया:
- sfGuardPlugin - उपयोगकर्ता प्रबंधन, सुरक्षा, आदि। प्लगइन - होना चाहिए।
- sfDateTimePlugin - दिनांक और समय के साथ बहुत सुविधाजनक काम
- sfPropelAlternativeSchemaPlugin - प्लगइन्स के साथ काम करते समय उपयोगी, आपको प्लगइन्स के कोड को बदलने के बिना प्लग इन में निर्दिष्ट मॉडल को बदलने की अनुमति देता है
- sfPropelApprovableBehaviorPlugin - मेरे लिए यह बहुत उपयोगी था जब "उपयोगकर्ता सक्रियण"
- sfThumbnailPlugin - छवि में कमी (नाम न देखें - 3MP फ़ोटो के आकार के साथ 800 × 600 प्लग-इन कॉप्स पूरी तरह से अच्छी तरह से)
- sfPropelActAsTaggableBehaviorPlugin - यदि आपको टैग की आवश्यकता है
- sfPropelActAsSluggableBehaviorPlugin - यदि आपको स्लग की आवश्यकता है (और मैं आपको उनका उपयोग करने की सलाह देता हूं - आईडी के बजाय स्लग लगाने पर यह url की पठनीयता पर बहुत अच्छा प्रभाव डालता है।
- sfPropelActAsRatableBehaviorPlugin - रेटिंग बहुत अच्छी हैं, दुर्भाग्य से उन्होंने मुझे सूट नहीं किया ...
- sfPropelActAsCommentableBehaviorPlugin - आप सभी टिप्पणियों के लिए की जरूरत है
व्यवस्थापक पैनल के लिए स्वचालित रूप से उत्पन्न CRUD- मॉड्यूल और मॉड्यूल का उपयोग करें

सिम्फनी: कैसे शुरू करें