सिद्धांत ओआरएम के साथ आपका अनुभव क्या है?

Question

doctrine के साथ आपका अनुभव क्या है? मैं कभी भी एक ओआरएम प्रकार का लड़का नहीं रहा हूं, मैं ज्यादातर adodb जैसे कुछ बुनियादी डीबी abstraction परत के साथ प्रबंधन किया।

लेकिन मैं इसकी सभी अवधारणाओं और लाभों को समझ गया। तो जब एक परियोजना के साथ एक ओआरएम की आवश्यकता थी तो मैंने सोचा कि मैं ओआरएम ढांचे में से एक को आज़मा दूंगा।

मुझे सिद्धांत और प्रोपेल के बीच निर्णय लेना है इसलिए मैं सिद्धांत चुनता हूं क्योंकि मैं फ़िंग आवश्यकता को संभालना नहीं चाहता था।

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

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

क्या कोई सुझाव दे सकता है या शायद मुझे इस विषय पर किसी अच्छे संसाधन या कुछ आधिकारिक साइट/व्यक्ति के बारे में बताएं? या शायद एक और ओआरएम ढांचा की सिफारिश करें जो 'बस काम करता है'?

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

हम 2 साल से सिम्फनी के साथ प्रोपेल का उपयोग कर रहे हैं और 1 साल से अधिक समय के लिए सिम्फनी के साथ सिद्धांत का उपयोग कर रहे हैं। मैं कह सकता हूं कि एमवीसी ढांचे के साथ ओआरएम में जाने का सबसे अच्छा कदम था। मैं सिद्धांत घटना के साथ चिपकने की सिफारिश करता हूं हालांकि इसमें कुछ समय लगता है कि इसके साथ कैसे काम करना है। अंत में आप अपना कोड अधिक पठनीय और लचीला पाएंगे।

यदि आप कुछ जगह कहां से शुरू कर रहे हैं, तो मैं सिम्फनी जॉबेट ट्यूटोरियल http://www.symfony-project.org/jobeet/1_4/Doctrine/en/ (अध्याय 3, 6 मूलभूत बातें शामिल करता हूं) और निश्चित रूप से डॉक्टरेट दस्तावेज की सिफारिश करता हूं।

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

Answer 4

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

Answer 5

मेरे पास मिश्रित भावनाएं हैं। मैं केवल एसक्यूएल में एक मास्टर हूं क्योंकि इसे सत्यापित करना इतना आसान है। आप परिणामों को सही होने तक त्वरित विवरणों का परीक्षण कर सकते हैं। और रिफैक्टर करने के लिए एक तस्वीर है।

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

मैं अजीब हूँ। एसक्यूएल के लिए समुदाय बड़ा है। सिद्धांत के लिए समुदाय/समर्थन कम है। निश्चित रूप से आप स्रोत को देख सकते हैं और इसे समझने की कोशिश कर सकते हैं ... और वे मुद्दे हैं जो समझने के लिए दिन लगते हैं।

नीचे पंक्ति: अपने आप को grokking के लिए बहुत समय में योजना के बिना, सिद्धांत, या किसी भी ओआरएम की कोशिश मत करो।

Answer 6

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

Answer 7

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

Answer 8

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

मुझे सिद्धांत के लिए एक समर्थक नहीं दिखता है, केवल विपक्ष।मुझे नहीं पता कि यह क्यों मौजूद है, और हर दिन मेरी इच्छा है कि यह नहीं (कम से कम मेरी परियोजनाओं में)।

Answer 9

2015 में डॉक्टर 2.5 का उपयोग करना। यह प्रतीत होता है कि यह अच्छी तरह से चल रहा था। जब तक मैं दो इकाइयों (जॉइन में) का उपयोग नहीं करना चाहता था।

• पैदा एसक्यूएल के लिए मुझे
• विदेशी कुंजी और रेफेरेंन्शिअल सत्यनिष्ठा के उपयोग
डिफ़ॉल्ट रूप से
• InnoDB पीढ़ी
• अपडेट किए हों:

  अच्छा [बेहतर अब के बाद मैं DQL का उपयोग करना सीख मिल गया है] डिक्ट्राइन कमांड लाइन उपकरण

ठीक है:

क्वेरी के कस्टम एपीआई सीखने - 210

• नामकरण और मैपिंग और कैसे की अति बारे में पता किया जा रहा है नाम के लिए और कैसे वास्तविक टेबल

बुरा

• लिए संस्थाओं को मैप करने में बहुत समय लेता है बिल्डर। या यह सोचकर कि एक साधारण जॉइन कैसे करें, यह सोचकर कि क्या बेहतर तकनीकें हैं .. सरल जॉइन को ऑब्जेक्ट उन्मुख प्रश्नों को करना चाहते हैं तो कस्टम फ़ंक्शन लिखने की आवश्यकता होती है।
• [पहली छाप पर अद्यतन ऊपर] - मैं के रूप में यह सबसे SQL को

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

मौजूदा परियोजनाओं

मैं में सिद्धांत सिद्धांत का उपयोग एक मौजूदा परियोजना पर नई सुविधाएं विकसित करने (बस शुरू कर रहा हूँ)। तो सुविधा के लिए उदाहरण के लिए नई mysql तालिका जोड़ने की बजाय, मैंने इकाइयों को जोड़ा है (जिसने सिद्धांत स्कीमा पीढ़ी का उपयोग करके मेरे लिए टेबल बनाए हैं)। मैं मौजूदा टेबल के लिए सिद्धांत का उपयोग नहीं कर रहा हूं जब तक कि मुझे यह बेहतर न हो जाए।

अगर मैं मौजूदा टेबल पर इसका इस्तेमाल करने के लिए गए थे, मैं पहले ... टेबल को साफ होगा, जिसमें शामिल है:

• आईडी स्तंभ जो एक प्राथमिक है/किराए की कुंजी
• जोड़ने InnoDB का उपयोग कर/लेन-देन-सक्षम तालिका
• नक्शा यह उचित रूप से एक इकाई के लिए
• रन सिद्धांत सत्यापित करें उपकरण (doctrine orm:validate-schema)

ऐसा इसलिए है क्योंकि सिद्धांत आपकी तालिकाओं के बारे में कुछ मान्यताओं को बनाता है। और क्योंकि आप अनिवार्य रूप से कोड के माध्यम से अपनी टेबल ड्राइव करने जा रहे हैं। तो आपका कोड और आपकी तालिकाओं को यथासंभव 1: 1 समझौते में होना चाहिए। इस प्रकार, सिद्धांत सामान्य रूप से किसी भी "मुक्त-रूप" तालिकाओं के लिए उपयुक्त नहीं है।

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

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

Answer 10

2016 में डॉक्टरेट ओआरएम का उपयोग लगभग 2 ~ 2.5 वर्षों के साथ।

निहित असंगति

SELECT i, p    
FROM \Entity\Item i 
JOIN i.product p 
WHERE ... 

मान लें संस्थाओं Item और Product हैं। वे Item.product_id से Product.id के माध्यम से जुड़े हुए हैं, और Product में Product.model है जो हम Item के साथ प्रदर्शित करना चाहते हैं।

यहाँ डेटाबेस से एक ही "product.model" की बहाली है, इसके बाद के संस्करण का उपयोग कर एसक्यूएल लेकिन SQL मानकों बदलती:

//SELECT i, p 
$ret[0]->getProduct()->getModel();   

//SELECT i as item, p as product 
$ret[0]['item']->getProduct()->getModel(); 

//SELECT i as item, p.model as model 
$ret[0]['model'];       

प्वाइंट मैं बनाने रहा हूँ यह है:

आउटपुट ResultSet संरचना को बदल सकते हैं आप अपने डीक्यूएल/ओआरएम चयन कथन लिखने के तरीके के आधार पर काफी हद तक निर्भर करते हैं।

ऑब्जेक्ट्स की सरणी से ऑब्जेक्टिव सरणी की सरणी से, एसोसिएटिव सरणी की सरणी के लिए, आप SELECT पर निर्भर करते हैं। कल्पना करें कि आपको अपने एसक्यूएल में बदलाव करना है, फिर कल्पना करें कि अपने कोड पर वापस जाएं और परिणाम सेट से डेटा पढ़ने के साथ जुड़े सभी कोड दोबारा करें। ओच! आउच! आउच! भले ही यह कोड की कुछ पंक्तियां हों, आप परिणाम सेट की संरचना पर निर्भर करते हैं, कोई पूर्ण decoupling/सामान्य मानक नहीं है।

क्या सिद्धांत

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

क्या सिद्धांत

पर बुरा है जब भी आप DQL/ORM के लिए किसी भी काफी उन्नत एसक्यूएल अनुवाद करने की आवश्यकता है, तो आप के लिए संघर्ष कर सकते हैं। उससे अलग, आप ऊपर की तरह असंगतताओं से भी निपट सकते हैं।

अंतिम विचार

मैं बनाने/मेरे लिए टेबल को संशोधित करने के लिए और वस्तुओं के लिए तालिका डेटा परिवर्तित करने, और उन्हें वापस बने, और तैयार बयान और अन्य नियंत्रण और संतुलन प्रयोग करने के लिए के लिए सिद्धांत से प्यार है, अपने डेटा को सुरक्षित बनाने ।

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

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

Answer 11

अभी के लिए मैं सिद्धांत ओआरएम, के साथ सिम्फनी ढांचे का उपयोग कर रहा हूं, सादे प्रश्नों के साथ सिद्धांत का उपयोग करने के बारे में कैसे? उदाहरण के लिए knpuniversity से, मैं कस्टम भंडार विधि बना सकते हैं जैसे:

 public function countNumberPrintedForCategory(Category $category) 
    { 
     $conn = $this->getEntityManager() 
      ->getConnection(); 
     $sql = ' 
      SELECT SUM(fc.numberPrinted) as fortunesPrinted, AVG(fc.numberPrinted) as fortunesAverage, cat.name 
      FROM fortune_cookie fc 
      INNER JOIN category cat ON cat.id = fc.category_id 
      WHERE fc.category_id = :category 
      '; 
     $stmt = $conn->prepare($sql); 
     $stmt->execute(array('category' => $category->getId())); 
     return $stmt->fetch(); 
... lines 30 - 37 
    } 

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