2015-06-30 6 views
6

एक सहयोगी के साथ चर्चा करने के बाद, हम मिश्रित होते हैं जहां हमें लगता है कि दृश्य से संबंधित तर्क जाना चाहिए।संख्या_format (दृश्य से संबंधित तर्क) को केकपीएचपी कहां जाना चाहिए?

उदाहरण के लिए कहें कि हमारे पास एक संख्या है जिसे हम अपने विचार में दिखाना चाहते हैं। मुझे लगता है कि number_format (या CakeNumber::format जैसा कि हम केकेपीएचपी का उपयोग कर रहे हैं) को दृश्य में जाना चाहिए क्योंकि यह हमारे द्वारा दिखाए जाने वाले कार्यों से संबंधित है। मेरे सहयोगी को लगता है कि इसे नियंत्रक में जाना चाहिए क्योंकि वह जगह है जहां सभी तर्क चलते हैं।

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

सवाल यह है कि, "अधिक" सही कौन है, उस नंबर स्वरूपण को कहां जाना चाहिए?

दृश्य में कोड डालने के मेरे तर्क के आगे, वह दृश्य में htmlentities का उपयोग करने में प्रसन्न है, लेकिन मुझे तर्क है कि अगर मुझे नंबर_फॉर्मेट की अनुमति नहीं है, तो उसके पास htmlentities नहीं हो सकता है और यह इसे किया जाना चाहिए नियंत्रक।

+0

मेरी राय, आप सही हैं। इसे देखने में जाना चाहिए क्योंकि इसका उपयोग केवल प्रारूपण उद्देश्यों के लिए किया जाता है (जैसे 'htmlentities') और एप्लिकेशन के व्यावसायिक तर्क के साथ कुछ भी नहीं करता है। – Carlos

+0

इम्हो, निश्चित रूप से नियंत्रक, दृश्य को कम से कम संचालन –

+2

@Answers_Seeker IMO करना है, नियंत्रकों को जितना संभव हो उतना पतला रखा जाना चाहिए। – Carlos

उत्तर

4

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

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

यह निश्चित रूप से मेरी सारी राय सामग्री को अलग रखने और सही जगह पर रखने की कोशिश कर रहे वर्षों से बनाई गई है, आपका लाभ भिन्न हो सकता है।

+0

ठीक है इसके साथ। "हेल्पर्स" अक्सर व्यू परत में विशिष्ट (दृश्य-उन्मुख) तर्क जोड़ने के लिए उपयोग किया जाता है। – Armage

+0

'सभी तर्क मॉडल में जाना चाहिए, नियंत्रक नहीं' एमवीसी के पौराणिक नियमों को छोड़कर (एमवीसी का क्या अर्थ है, केक की एमवीपी के करीब तर्क है) केकपीएचपी _presentational_ तर्क जैसे एचटीएमएल इकाइयों से बचने के लिए _does not_ go मॉडल में – AD7six

+0

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

1

मेरे सहकर्मी चीजें इसे नियंत्रक में जाना चाहिए क्योंकि वह सब तर्क है।

कोई व्यावसायिक तर्क नियंत्रक में नहीं जाता है। यह एमवीसी नहीं है। यह एक अत्याचार है।

इस तरह के मामलों में, हमेशा एक परिदृश्य की कल्पना करें कि एमवीसी मुख्य रूप से डिज़ाइन किया गया था: वैकल्पिक नियंत्रक के लिए अपने नियंत्रक/दृश्य को स्वैप करें। उदाहरण के लिए, अपने ऐप के लिए कमांड लाइन क्लाइंट लिखने की कल्पना करें, उदा। प्रशासनिक बैकएंड कार्यों को करने के लिए।

$ admin users create Bob [email protected] 

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

और स्वरूपण संख्या स्पष्ट रूप से दृश्य की ज़िम्मेदारी है, क्योंकि यह एक दृश्य, मानव-पठनीय चिंता है।

+4

"केक अक्सर कोड से भरा अपने नियंत्रक को भरने की भयानक प्रथा को बढ़ावा देता है" विस्तृत करने के लिए देखभाल? –

+2

मैंने सोचा कि मैंने किया था। व्यवसाय तर्क से भरे कंट्रोलर भरना ऊपर उल्लिखित कारणों के लिए सादा गलत है। एक नियंत्रक मॉडल/दृश्य और वास्तविक दुनिया के बीच गोंद का थोड़ा सा है। न कुछ ज्यादा, न कुछ कम। – deceze

+3

मुझे पूरा यकीन है कि आधिकारिक दस्तावेज का कोई भी * इस पर प्रचार नहीं करता है। वास्तव में बहुत से लोग गलत करते हैं लेकिन यह स्पष्ट रूप से ** ** ढांचे द्वारा प्रचारित नहीं है। एकमात्र चीज जिसके साथ मैं सहमत हूं वह यह है कि इसमें सेवा परत की कमी है। – burzum

1

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

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

+0

दृश्य प्रस्तुतकर्ताओं का एक उदाहरण शायद पाठक की मदद करेगा। [ऐसा कुछ] [https://gist.github.com/AD7six/dc17c2e1f7d7c14ecbd4)। – AD7six

5

उदाहरण के लिए कहें कि हमारे पास एक संख्या है जिसे हम अपने विचार में दिखाना चाहते हैं। मुझे लगता है कि number_format (या केकएनंबर :: प्रारूप जैसा कि हम केकेपीएचपी का उपयोग कर रहे हैं) को दृश्य में जाना चाहिए क्योंकि यह हमारे द्वारा दिखाए जाने वाले कार्यों से संबंधित है। मेरे सहयोगी को लगता है कि इसे नियंत्रक में जाना चाहिए क्योंकि वह जगह है जहां सभी तर्क चलते हैं।

आपका दोस्त गलत है। आपको वास्तव में NumberHelper का उपयोग करना चाहिए जो स्थिर केक नम्बर के चारों ओर एक रैपर है। आप आमतौर पर अपने ऐप में स्टेटिक्स और सिंगलेट्स से बचना चाहते हैं, एक सहायक को भी अलियाड किया जा सकता है, इसलिए विचारों में नंबरहेल्पर का उपयोग करें। दृश्य सही जगह है।

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

नियंत्रक को जेसन और अन्य आउटपुट का समर्थन करने के लिए एक पंक्ति बदलने की आवश्यकता नहीं है। खैर, आप देख सकते हैं कि दृश्य vars के अंतर्निहित क्रमशः json/xml या कस्टम जेसन दृश्य बनाएं। Read this chapter. हालांकि, दो विधियों को बनाने या नियंत्रक को व्यापार तर्क के साथ भरने की कोई आवश्यकता नहीं है जो वास्तव में गलत है।

सवाल यह है कि, "अधिक" सही कौन है, उस नंबर स्वरूपण को कहां जाना चाहिए?

निश्चित रूप से दृश्य।

एक नियंत्रक पतला होना चाहिए और किसी भी व्यापार तर्क को शामिल नहीं:

enter image description here

इसके अलावा ध्यान में रखते हुए कोड डालने की मेरी तर्क को

, वह दृश्य में htmlentities का उपयोग करने के लिए खुश है, लेकिन मैं बहस अगर मुझे नंबर_फॉर्मेट की अनुमति नहीं है, तो उसके पास HTML नहीं हो सकता है और यह नियंत्रक में किया जाना चाहिए।

h() का उपयोग करें जो htmlspecialchars() के लिए शॉर्टकट है। और सुनिश्चित करें कि आप सब कुछ के लिए इसका उपयोग करते हैं, तो आप इसे प्रतिबिंबित करते हैं। ढांचे के साथ आने वाले सभी मूल सहायक लोग आंतरिक रूप से आपके लिए ऐसा करेंगे यदि आप उनके माध्यम से कुछ पास करते हैं लेकिन तीसरे पक्ष के सहायकों पर ध्यान देते हैं जो इसका उपयोग नहीं कर सकते हैं!

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