एक ही कार्यक्षमता की पेशकश करने वाले दो घटक, विभिन्न निर्भरताओं द्वारा आवश्यक


9

मैं ORM परत के रूप में Zend फ्रेमवर्क 1 और Doctrine2 का उपयोग करके PHP में एक एप्लिकेशन बना रहा हूं। सब ठीक चल रहा है। अब, मैं नोटिस करने के लिए हुआ कि ZF1 और Doctrine2 दोनों साथ आते हैं, और अपने स्वयं के कैशिंग कार्यान्वयन पर भरोसा करते हैं। मैंने दोनों का मूल्यांकन किया है, और जबकि प्रत्येक की अपनी समर्थक और विपक्ष है, दोनों में से कोई भी मेरी साधारण जरूरतों के लिए दूसरे से बेहतर नहीं है। दोनों पुस्तकालयों को भी उनके कार्यान्वयन के खिलाफ नहीं बल्कि उनके संबंधित इंटरफेस के खिलाफ लिखा गया लगता है।

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

मैं यह निर्धारित करने की कोशिश कर रहा हूं कि आगे का सबसे अच्छा तरीका क्या है, और किसी भी अंतर्दृष्टि का स्वागत करेंगे जो आप पेश कर सकते हैं।

मैंने सोचा कि अब तक चार विकल्प हैं:

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

क्या विकल्प सबसे अच्छा है, या "उपरोक्त में से कोई नहीं" संस्करण है जो मुझे नहीं पता है?


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

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

Symfony2 पर एक नज़र डालें और उन्होंने इस समस्या से कैसे निपटा।
नीटोनफिर

जवाबों:


7

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

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

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

मुझे पता है कि बूटस्ट्रैप में यह कई कैश को सेटअप करने के लिए बेमानी लग सकता है। यदि आप ZF1, Doctrine और ZF2 का एक साथ उपयोग करने का प्रयास करते हैं तो यह खराब हो सकता है। लेकिन यह एक बहुत छोटा स्थिर समय होता है क्योंकि वे केवल परिवर्तनशील चर होते हैं, जो पीछे के छोर से नहीं जुड़ते हैं।

इसलिए, प्रोग्रामिंग, रखरखाव और संचालन के दृष्टिकोण से, मैं उन्हें अकेला छोड़ दूँगा।


3

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

केवल "कॉन्फ़िगरेशन को अधिक सुविधाजनक बनाने" के दृष्टिकोण से समस्या से क्यों नहीं निपटना चाहिए?

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


0

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

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