क्या मुझे डॉक्ट्रिन 2 या प्रोपेल 1.5 / 1.6 चुनना चाहिए, और क्यों? [बन्द है]


30

मैं उन लोगों से सुनना चाहता हूं जिन्होंने डॉक्ट्रिन 2 (या बाद में) और प्रोपेल 1.5 (या बाद में) का उपयोग किया है। इन दो ऑब्जेक्ट रिलेशनल मैपर्स के बीच अधिकांश तुलना पुराने संस्करणों पर आधारित है - डॉक्ट्रिन 1 बनाम प्रोपेल 1.3 / 1.4, और दोनों ओआरएम अपने हाल के संशोधनों में महत्वपूर्ण रीडिज़ाइन के माध्यम से गए। उदाहरण के लिए, प्रोपेल की अधिकांश आलोचना "मॉडलनाम पीर " कक्षाओं के आसपास केंद्रित होती है, जो किसी भी मामले में 1.5 में चित्रित किए गए हैं।

यहाँ मैंने जो अभी तक संचित किया है (और मैंने इस सूची को यथासंभव संतुलित करने की कोशिश की है ...):

  • प्रोपेल
    • पेशेवरों
      • PHP मैजिक मेथड्स पर निर्भर होने के बजाए, वास्तविक IDE के अनुकूल, क्योंकि वास्तविक कोड उत्पन्न होता है। इसका मतलब है कि कोड पूरा होने जैसे आईडीई फीचर्स वास्तव में मददगार हैं।
      • उपवास (डेटाबेस के उपयोग के संदर्भ में - डेटाबेस पर कोई रनटाइम आत्मनिरीक्षण नहीं किया जाता है)
      • स्कीमा संस्करणों के बीच स्वच्छ प्रवास (कम से कम 1.6 बीटा में)
      • PHP 5.3 मॉडल (यानी नामस्थान) उत्पन्न कर सकते हैं
      • useXxxतरीकों की तरह चीजों के साथ एक ही डेटाबेस क्वेरी में बहुत सी चीजों को चेन करना आसान है । (ऊपर "कोड पूरा" वीडियो देखें)
    • विपक्ष
      • मॉडल कक्षाओं के निर्माण के लिए एक अतिरिक्त बिल्ड स्टेप की आवश्यकता होती है।
      • जब भी प्रोपेल वर्जन बदला जाता है, एक सेटिंग बदली जाती है, या स्कीमा परिवर्तित होता है, तब जेनरेट किए गए कोड की आवश्यकता होती है। यह मॉडल के लिए लागू कुछ और कस्टम तरीकों के लिए अनजाना हो सकता है। (मुझे लगता है; ) - सच नहीं है; कस्टम तरीके खोए नहीं हैं क्योंकि उत्पन्न वर्ग एक आधार वर्ग है; प्रोपेल विशेष रूप से विस्तार के लिए एक इकाई वर्ग प्रदान करता है।
      • कुछ उपयोगी सुविधाएँ (अर्थात संस्करण व्यवहार, स्कीमा माइग्रेशन) बीटा स्थिति में हैं।
  • सिद्धांत
    • पेशेवरों
      • अधिक लोकप्रिय
      • डॉक्ट्रिन क्वेरी लैंग्वेज डेटा के बीच संभावित रूप से अधिक जटिल रिश्तों को आसानी से प्रोपल की ActiveRecord रणनीति के साथ व्यक्त कर सकती है।
      • प्रोपेल की तुलना में पुन: प्रयोज्य व्यवहारों को जोड़ने में आसान।
      • स्कीमा के निर्माण के लिए DocBlock आधारित टिप्पणी एक अलग XML फ़ाइल के बजाय वास्तविक PHP में एम्बेडेड है।
      • हर जगह PHP 5.3 नाम स्थान का उपयोग करता है
    • विपक्ष
      • एक पूरी तरह से नई प्रोग्रामिंग भाषा सीखने की आवश्यकता है (सिद्धांत क्वेरी भाषा)
      • कई स्थानों पर "जादू के तरीकों" के रूप में लागू किया गया, जिससे आईडीई स्वत: पूर्ण बेकार हो गई।
      • डेटाबेस आत्मनिरीक्षण की आवश्यकता है और इस प्रकार डिफ़ॉल्ट रूप से प्रोपेल की तुलना में थोड़ा धीमा है; कैशिंग इसे हटा सकता है लेकिन कैशिंग काफी जटिलता जोड़ता है।
      • कोर कोडबेस में कम व्यवहार शामिल हैं। Propel कई सुविधाएँ बॉक्स से बाहर प्रदान करता है (जैसे नेस्टेड सेट) केवल एक्सटेंशन के माध्यम से उपलब्ध हैं।
      • फ्रीकिन की बड़ी :)

हालांकि, मैंने केवल दोनों टूल के लिए उपलब्ध प्रलेखन को पढ़ने के माध्यम से चमक दी है - मैंने वास्तव में अभी तक कुछ भी नहीं बनाया है।

मैं उन लोगों से सुनना चाहता हूं, जिन्होंने प्रत्येक पुस्तकालय के पेशेवरों / विपक्षों पर अपने अनुभव को साझा करने के लिए दोनों उपकरणों का उपयोग किया है, और इस बिंदु पर उनकी सिफारिश क्या है :)


आप किस सिद्धांत के बारे में बात कर रहे हैं? v2 और v1.2 पोल अलग हैं।
परिक्रमा

1
@Orbling: क्या आपने शीर्षक या प्रश्न का शरीर पढ़ा है? उन्हें फिर से पढ़ें :)
बिली ओनली

@ बिली ओनली: अच्छी बात है। Doctrine2 में कोर से पूरी तरह से हटाए गए व्यवहार हैं, इसलिए मैंने सोचा कि आप इसके बजाय v1.2 के बारे में बोल रहे होंगे।
परिक्रमा

@Orbling: आह, यह समझ में आता है। दूसरी ओर यह "व्यवहार" के समकक्ष प्रदान करता है - यह सिर्फ उन्हें कॉल नहीं करता है।
बिली ओनली

@ बिली ओनली: यह वास्तव में नहीं है, आप उन्हें अपने आप को काफी आसान तरीके से लागू कर सकते हैं, या आप तीसरे पक्ष के प्लगइन्स प्राप्त कर सकते हैं। लेकिन यह Doctrine1 या Propel जैसा नहीं है।
शाम

जवाबों:


15

सिद्धांत की सिफारिश करने के लिए वर्तमान प्रवृत्ति को समाप्त करें, मुझे अन्यथा कहने की आवश्यकता है। यह भी ध्यान रखें कि, मेरी व्यक्तिगत प्राथमिकताएं मेरे व्यक्तिगत अनुभवों के लिए उन्मुख हैं, लेकिन @Dan ने कैसे कहा, वे दोनों बहुत शक्तिशाली हैं।

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

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

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

आशा है कि मैं मदद कर सकता हूँ


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

11

Doctrine 2 के बारे में आपकी जानकारी गलत है ...

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

मैंने पहले प्रोपेल का उपयोग नहीं किया है, लेकिन डॉक्ट्रिन 2 बहुत नया है और वास्तव में उच्च गुणवत्ता वाला कोडबेस है। लेकिन ऐसा लगता है कि प्रोपेल एक्टिव रिकॉर्ड का उपयोग करता है, डॉक्ट्रिन 2 डेटा मैपर पैटर्न का उपयोग करता है।

डॉक्ट्रिन 2 का नया होना तीसरे पक्ष के उदाहरणों की कमी है, लेकिन यह जल्दी से निर्माण कर रहा है।

मैं 2 सिद्धांत की सिफारिश ...


यदि आपने पहले से प्रोपेल का उपयोग नहीं किया है तो मेरे पास FUD होने के कारण इसे अस्वीकार करने के अलावा कोई विकल्प नहीं है। "मैजिक" टिप्पणी के लिए, मेरा मतलब है कि यह वास्तविक तरीकों के बजाय PHP मैजिक विधियों जैसे ( __getऔर __setजो सच है) पर आधारित है ।
बिली ओनेल

1
डाउन वोट के लिए ठीक है ... लेकिन डॉक्ट्रिन 2 जादू के तरीकों का उपयोग कहां करता है? डॉक्यूमेंटरीपॉजिटरी के पास * तरीके (__call) मिलते हैं, लेकिन यह कोई समस्या नहीं है क्योंकि यह क्वेरी करने का सिर्फ एक अच्छा तरीका है ... आप हमेशा आईडीई स्वत: पूर्णता खो देंगे। यदि आप ActiveRecord Propel का उपयोग करना चाहते हैं। यदि आप डेटा मैपर चाहते हैं, तो Doctrine 2 का उपयोग करें
Cobby

2
कोड पीढ़ी की बदौलत प्रोपेल रनटाइम पर डेटाबेस का निरीक्षण नहीं करता है।
विलियम डूरंड

बुलेट आइटम # 1 पूरी तरह से सही नहीं है, DQL SQL की तरह "बहुत ज्यादा" नहीं है। DQL इस तथ्य पर निर्भर करता है कि आप मॉडल ऑब्जेक्ट्स का संदर्भ दे रहे हैं जो कि Doctrine को पता होना चाहिए, और कुछ जटिलताएं हैं यदि अधिक जटिल जोड़ आवश्यक हैं।
माइक पर्सल

2
DQL SQL की एक बोली है, यह कैसे SQL की तरह "बहुत ज्यादा" नहीं बनाता है? हां, भाषा के शब्दार्थ थोड़े भिन्न (ऑब्जेक्ट्स बनाम टेबल) हैं, लेकिन अंततः DQL संरचित डेटा को क्वेरी करने के लिए भाषा है - जो कि सिर्फ टेबल नहीं वस्तुओं के रूप में प्रतिनिधित्व करने के लिए हुआ - उर्फ ​​SQL।
4

3

आपकी टिप्पणियों से, ऐसा लगता है कि आप लेग आवेदन में ओआरएम की आवश्यकता को बदलने या पूरा करने के लिए प्रोपेल या डॉक्ट्रिन को लेने की कोशिश कर रहे हैं।

यह कहा जा रहा है, मुझे लगता है कि इस तथ्य को नहीं खोना महत्वपूर्ण है कि किसी एक को स्थानांतरित करने से आपके आवेदन में काफी सुधार हो सकता है। तो, कोई गलत गलत जवाब नहीं है।

इसलिए, आपके द्वारा लिया गया समाधान काफी हद तक आपकी प्राथमिकताओं पर निर्भर करता है, क्योंकि आप निम्नलिखित सवालों के जवाब देते हैं:

  1. आपके वर्तमान समाधान में कौन सा सबसे अच्छा एकीकृत है?
  2. आपको कौन सा एपीआई पसंद है?
  3. आप किस पर योगदान देंगे? (पैच, प्रलेखन, बग रिपोर्ट, आदि ...)

व्यक्तिगत रूप से, मैं समुदाय, प्रलेखन और वास्तुकला के कारण डॉक्ट्रिन 2 की सिफारिश करूंगा ।


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

2
ओह, आपको डॉक्ट्रिन डॉक पसंद है? क्या आपने प्रोपेल को पढ़ा था? और हां, डॉक्ट्रिन समुदाय अच्छा है, लेकिन ODM रिपॉजिटरी पर एक नज़र डालें, बहुत सारे पीआरएस पर टिप्पणी भी नहीं की गई है और न ही विलय किया गया है और न ही खारिज किया गया है ... प्रोपल टाइमलाइन देखें, समुदाय वास्तव में सक्रिय है;)
विलियम डूरंड

3

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

Doctrine2 का कोई आधिकारिक व्यवहार नहीं है, और DataMapper डिजाइन पैटर्न शांत है लेकिन वास्तविक जीवन में उपयोग करने के लिए कठिन है। ओह और DQL एक दर्द है, फिर भी जानने के लिए अब्रॉड भाषा ...

यदि आप वस्तुओं (कोई DQL / SQL / जो भी) के साथ सोचना चाहते हैं, तो Propel चुनें।

Doctrine2 Symfony2 de facto का हिस्सा है, लेकिन चीजें बहुत जल्द ही आगे बढ़ेंगी, अंतिम फैबिएन पोटेंसीयर लेख देखें।

चीयर्स, विलियम


, मैंने 2 साल पहले Propf के साथ symfony1 के साथ शुरुआत की थी। तब symfony2 के लिए Doctrine2 पर स्विच करना पड़ा। Propel.heheers पर वापस जाने के लिए शुभकामनाएँ!
भानु कृष्णन

2

वे दोनों बहुत अच्छे हैं। कुछ किनारे मामले हैं जिनमें एक दूसरे से कुछ कर सकता है, या कुछ बेहतर कर सकता है। जहाँ भी मुझे समस्याओं का सामना करना पड़ा है, यह मेरे ज्ञान की कमी के कारण था क्योंकि वे ऐसा नहीं कर सकते थे।

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


2

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.