6

मैं जावा/ग्रेल्स पृष्ठभूमि से आया हूं और मुझे एक निश्चित उत्तर ऑनलाइन नहीं मिल रहा है, जहां केकेपीएचपी एप्लिकेशन के लिए सेवा तर्क संग्रहीत किया जाना चाहिए। "सेवाओं" द्वारा, मैं कक्षाओं के बारे में बात कर रहा हूं जो आमतौर पर डोमेन ऑब्जेक्ट्स पर व्यावसायिक तर्क करने के लिए निर्भरता इंजेक्शन के माध्यम से तत्काल होते हैं। वे किसी भी डोमेन ऑब्जेक्ट से पूछने और नियंत्रक कार्रवाई के जवाब में परिवर्तन करने में सक्षम होना चाहिए।केकपीएचपी: 'सर्विसेज' तर्क कहां रखा जाए

वर्तमान में, केकपीएचपी का "घटक" वर्ग इस व्यवहार का सबसे निकटतम मैच प्रतीत होता है। मैं किसी भी नियंत्रक में एक घटक लोड कर सकता हूं और आवश्यकतानुसार इसकी विधियों को निष्पादित कर सकता हूं। हालांकि, मैंने कई स्थानों पर पढ़ा है कि घटकों को कभी भी डेटाबेस तक नहीं पहुंचना चाहिए और ऐसा करने से कुछ तेज प्रदर्शन हिट हो जाएंगी।

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

तो मैं इस सवाल से पूछता हूं: सेवा तर्क कहां से संग्रहीत किया जाना चाहिए? निश्चित रूप से नियंत्रक नहीं, क्योंकि इसमें अनुरोध को संसाधित करने और प्रतिक्रिया भेजने के लिए केवल न्यूनतम तर्क होना चाहिए।

+1

यहां आपके लिए एक निशुल्क संकेत है: केकेपीएचपी से दूर रहें। यह PHP में सबसे खराब ढांचे में से एक है और यह निश्चित रूप से एमवीसी की तरह दूरस्थ रूप से कुछ भी लागू नहीं करता है। अगर ऐसा कुछ ऐसा करना चाहते हैं जो कम से कम "सेवाओं" की अवधारणा को पहचान ले, तो आप Symfony2 को आजमा सकते हैं। –

+0

तर्क 1: वैश्विक राज्य। केकेपीएचपी मूल रूप से सिंगलेट्स और अन्य स्थैतिक रूप से स्कॉप्ड पैरामीटर के उपयोग के आसपास आधार है। –

+0

तर्क 2: स्थैतिक वर्ग: केकपीएचपी कोर के अधिकांश में स्थिर तरीके होते हैं। इससे सभी कोड कड़ाई से कक्षाओं के विशिष्ट नामों के साथ मिलते हैं, जो नामस्थान के रूप में उपयोग किए जाते हैं। –

उत्तर

6

घटक केकपीएचपी में सेवा परत हैं। वे एक निर्भरता इंजेक्शन कंटेनर (घटक संग्रह) द्वारा निर्मित होते हैं और नियंत्रित करने के लिए नियंत्रक, अनुरोध और प्रतिक्रिया पारित करते हैं।

परतों के बीच अलगाव बनाए रखने के अलावा घटक क्या कर सकते हैं इसमें कोई प्रतिबंध नहीं हैं। डेटाबेस कनेक्शन का उपयोग करना ठीक है, या सीधे घटक से मॉडल का उपयोग करें और अनुरोध को संशोधित करें।

घटक वास्तव में बहुत हल्के वजन वाले होते हैं यदि आप केवल उन्हें विशिष्ट मामलों के लिए कार्य करते हैं। कार्रवाई नाम का निरीक्षण, एक घटक की पहुंच सीमित करने का एक आम तरीका है। आप सेटिंग इंजेक्ट भी कर सकते हैं ताकि यह पता चल सके कि कस्टम सेवा तर्क निष्पादित करने के लिए ठीक कब है।

-2

तो मैं इस सवाल से पूछता हूं: सेवा तर्क कहां से संग्रहीत किया जाना चाहिए? निश्चित रूप से नियंत्रक नहीं है, क्योंकि इसमें अनुरोध को संसाधित करने और प्रतिक्रिया भेजने के लिए केवल न्यूनतम तर्क होना चाहिए।

Dispatcher Filter के लिए आदर्श उपयोग केस की तरह लगता है। नियंत्रक को तुरंत चालू करने से पहले इसे बुलाया जाता है। यदि आपको डेटाबेस से पूछताछ की आवश्यकता है तो बस क्लास रजिस्ट्री :: init ('YourModelName') के माध्यम से एक मॉडल लोड करें और अनुरोध विधि को मॉडल विधि में पास करें और जो भी आपको अपने अनुरोध में लौटाएं। कोई नियंत्रक बिल्कुल जरूरी नहीं है। हमने कभी भी नियंत्रक को कॉल किए बिना डिस्पैचर फ़िल्टर का उपयोग करके outh + xhttp लागू किया है।

किसी घटक के अंदर मॉडल का उपयोग करने से प्रदर्शन को प्रभावित करना चाहिए ... मुझे नहीं पता कि यह अजीब विचार किसने पाया, ऐसा लगता है कि आपको सबसे अच्छा लेख नहीं मिला है। यह सच है कि आपको उनमें मॉडल परत से संबंधित तर्क नहीं डालना चाहिए, लेकिन आप उदाहरण के लिए नियंत्रक उदाहरण और नियंत्रक मॉडल के माध्यम से मॉडल को कॉल कर सकते हैं।

+0

"सेवा तर्क" ज्यादातर भंडारण abstractions और डोमेन इकाइयों के बीच बातचीत का प्रतिनिधित्व करता है। आपके उत्तर के साथ इसके साथ कुछ लेना देना नहीं है। नरक .. केक मॉडल परत के दोनों पहलुओं को भी अलग नहीं करता है, क्योंकि यह अपने 'एपमोडेल' कक्षाओं के लिए सक्रिय रिकॉर्ड का उपयोग करता है। –

+0

@burzum कुछ पढ़ने के बाद, मुझे लगता है कि डिस्पैचरफ़िल्टर एपीआई कॉल जैसे कार्यों के लिए बहुत अच्छा होगा। हालांकि, मेरा अधिकांश तर्क प्रकृति में व्यापक है। उदाहरण के लिए, जब मुझे एक POST अनुरोध प्राप्त होता है जो प्रमाणीकरण विफल रहा है, तो मुझे डेटाबेस में विफल लॉगिन प्रयास लॉग करने की आवश्यकता है। हालांकि एक साधारण अवधारणा, एक नया रिकॉर्ड तत्काल करने के लिए काफी कोड मौजूद है, सत्यापित करें और इसे जारी रखें। इस प्रकार की गणना नियंत्रक में नहीं है, क्योंकि यह सीधे अनुरोध या प्रतिक्रिया से संबंधित नहीं है। क्या आप अभी भी ऐसे कार्य के लिए डिस्पैचरफ़िल्टर की अनुशंसा करेंगे? – emagdne

+1

डिस्पैचर फ़िल्टर मिडलवेयर तर्क के लिए अच्छे हैं, लेकिन घटक जो वर्णन कर रहे हैं उसके लिए बेहतर फिट हैं –

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