2009-03-17 9 views
10

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

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

अब, ज़ेंड चुनने के पीछे इस छोटे तर्क के बाद, फ्रेमवर्क चुनते समय कई चीजें मैं एक सौदा ब्रेकर के रूप में देखती हूं।

  • मैंने पहले भी ORM उपयोग नहीं किया है, क्योंकि मैं आराम से लेखन एसक्यूएल सीधे की तुलना में अधिक रहा हूँ, इसलिए मैं अभी भी ORM उपयोग करने के लिए आश्वस्त होने की जरूरत है
  • बहुत ज्यादा अमूर्त हिम्मत से चल रहा
  • लचीले निर्देशिका संरचना

जब तक इस परियोजना के नए सिरे से लिखा जा रहा है, मैं इसे अजगर/Django में लिखने बस के रूप में हो सकता है, के बाद से मैं अजगर के साथ काफी परिचित हूँ, लेकिन नहीं Django के साथ। तो, मैं जानना चाहूंगा कि क्या कोई ऐसा व्यक्ति है जो ज़ेंड फ्रेमवर्क और डीजेगो फ्रेमवर्क दोनों के साथ काम करता है और यदि कुछ महत्वपूर्ण बिंदु अंतरों को रेखांकित कर सकता है?

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

मुझे अभी भी यह सुनिश्चित नहीं है कि कोई मूल रूप से दो अनुप्रयोगों की निर्देशिका संरचना के भीतर कैसे काम करता है, जो एक माना जाता है, एक आवेदन है। क्या आप सिर्फ दो अलग-अलग एप्लिकेशन बनाते हैं और उन्हें अलग करने के लिए वहां से यूआरएल योजना पर भरोसा करते हैं? www.example.com और सभी/* एक आवेदन और www.example.com/admin/* एक दूसरा आवेदन है।

लंबे सवाल (रों) के लिए क्षमा करें, लेकिन जैसा कि आप देख सकते हैं - सब कुछ काफी एक समस्या से संबंधित है - मैं एक परियोजना नए सिरे से शुरू करने की आवश्यकता है, यह पहले से ही डेटाबेस + डेटा जो मैं फिर से कर सकते हैं की स्थापना की है, लेकिन कम से कम उस तरह के काम को रखना चाहते हैं।


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

+1

मैं वास्तव में Zend_Db को ओआरएम नहीं कहूंगा - यह एक ऑब्जेक्ट उन्मुख SQL इंटरफ़ेस है। यह कुछ अवशोषण प्रदान करता है जो आपके जीवन को आसान बनाता है, लेकिन यह उस कार्यक्षमता से काफी कम हो जाता है जो एक ओआरएम प्रदान करेगा। मैं इसे डिंग नहीं कर रहा हूं - यह ओआरएम होने का मतलब नहीं है। –

उत्तर

5

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

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

दो व्यवस्थापक और फ्रंटेंड को अलग करने के संबंध में मैं उन्हें विभिन्न डोमेन पर डालने का सुझाव दूंगा, उदाहरण: admin.yoursite.com (बैकएंड) और www.yoursite.com (फ्रंटएंड)। आप शायद उन्हें एक ही यूआरएल पर रखने के साथ काम कर सकते हैं लेकिन यह वास्तव में उपयोग-मामला नहीं है जो Django या Zend द्वारा समर्थित है।

+0

यह ज़ेंडफ थ्रू मॉड्यूल द्वारा समर्थित है ... लेकिन फिर फिर जवाब पुराना है! –

12

अच्छी तरह से Django ज़ेंड की तुलना में अधिक पूर्ण ढांचा ढांचा है।यह ज़ेंड की तुलना में सिम्फनी के समान है।

Django आपके डेटाबेस को ओआरएम कक्षाओं में इंजीनियर कर सकता है। और इसमें एक क्ली टूल है जो आपको सामान (व्यवस्थापक और मॉडल जनरेटर, प्रोजेक्ट कंकाल उत्पादन आदि) की मदद करता है

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

आपके मामले में Django के अपने महान व्यवस्थापक जनरेटर मॉड्यूल के कारण कुछ फायदे होंगे, और Django स्वयं बहुत तेज़ (अधिकतर PHP ढांचे की तुलना में तेज़) है।

मैं व्यक्तिगत रूप से कुछ सामान (मेल, ओपनआईडी, लुसीन सर्च) के लिए ज़ेंड फ्रेमवर्क के साथ सिम्फनी का उपयोग कर रहा हूं, लेकिन मैंने Django के साथ थोड़ा सा खेला है और मुझे यह पसंद है।

2

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

नीचे की रेखा है, ज़ेंड ज्यादातर "प्रेजेंटेशन फ्रेमवर्क" है। यही वह है जो इसे उत्कृष्ट बनाता है। यह आपको प्रस्तुति (स्क्रीन) को व्यवस्थित करने का एक साफ तरीका प्रदान करता है जो आपके उपयोगकर्ताओं को दिखाया जाता है और रखरखाव में सहायता करता है।

यह डेटा परिप्रेक्ष्य से आपके लिए बहुत कुछ नहीं करता है। यह आपके ऊपर है, और संभवतः 9 0% काम है जिसे "रखरखाव" बनने के लिए किया जाना चाहिए।

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

इसके अलावा, मैं प्रदर्शन के साथ खुद को चिंता नहीं करता ... मस्सी चीजें एक अच्छी कैशिंग रणनीति के साथ तय कर सकती हैं।

1

मैं ज़ेंड और डीजेगो के बीच तुलना नहीं कर सकता, लेकिन मैं आपको बता सकता हूं कि Django "admin" एप्लिकेशन को एक अलग डोमेन (वर्चुअल नाम सर्वर) पर चलाने के लिए पूरी तरह से संभव है, और आपको किसी को डुप्लिकेट करने की आवश्यकता नहीं है कोड। आप बस अपने Django ऐप को सामान्य के रूप में बनाते हैं लेकिन व्यवस्थापक ऐप और यूआरएल को एक अलग वर्चुअल सर्वर में डालते हैं जो एक सामान्य डेटाबेस सर्वर/क्लस्टर साझा करता है।

Django व्यवस्थापक ऐप की सीमाएं हैं, लेकिन यह लगभग कुछ मुफ्त के लिए बहुत शक्तिशाली है।

आखिरकार, जब मैंने पहली बार Django शुरू किया था तो मुझे आम तौर पर ओआरएम के लिए बहुत अधिक असंतोष था लेकिन मैं अब टूलबॉक्स में एक उपयोगी टूल के रूप में उन्हें स्वीकार करता हूं।

संबंधित मुद्दे