Zend फ्रेमवर्क आवेदन डिजाइन - सत्र चर मॉडल परत

Question

मैं इस अनुप्रयोग है कि मॉडल परत में सत्र चर तक पहुँचता है पर काम कर रहा हूँ एक्सेस किया जाना है। यह सिर्फ गलत लगता है लेकिन गलत साबित होने के लिए तैयार हूं। शायद गलत नहीं है, लेकिन ऐप में अधिकांश स्थानों में, सत्र चर को नियंत्रक में संभाला जाता है और तर्क के रूप में पारित किया जाता है, लेकिन अन्य स्थानों पर, सत्र मान को अभी तक एक्सेस किया जाता है। क्या मैं गलत हूं कि यह बुरा अभ्यास की तरह लगता है?

संपादित करें: एक कारण मैं मॉडल में सत्र पसंद नहीं है कि यह यह और अधिक जटिल परीक्षण करने के लिए बनाने के लिए लगता है। इसे केवल कार्यों के लिए पारित पैराम के रूप में रखें और फिर रिकॉर्डसेट वापस पास हो गया।

thx

Answer 1

यह निर्भर करता है।

तरह से मैं इस बारे में सोचते ऐसी है:

1. एक मॉडल आपका डेटा स्तर का प्रतिनिधित्व करता है।
2. अधिकांश समय डेटा परत डीबी टेबल आधारित
3. सत्र एक और डेटा संग्रहण माध्यम है।
4. निष्कर्ष: डेटा है कि अपने मॉडल का प्रतिनिधित्व करता है सत्र में संग्रहीत किया जाता है, की तुलना में यह ठीक है मॉडल

एक उदाहरण के भीतर से है कि डेटा तक पहुंचने का सत्र आधारित खरीदारी की टोकरी है। मेरे कार्ट की ऑब्जेक्ट्स मेरे सत्र डेटा के मॉडल हैं।

Answer 2

नियंत्रक एस एच डी एक चेक मौसम सत्र भी मौजूद हैं या मॉडल है जो इसके अंदर उस सत्र का उपयोग करता है उपयोग करने से पहले नहीं।

Answer 3

क्या सत्र चर में संग्रहीत है? अगर यह बस 'लॉग इन है? वाई/एन ', तो उन्हें शायद मॉडल परत का हिस्सा बनने की आवश्यकता नहीं है। यदि, हालांकि, यह उससे अधिक जटिल है, तो संभवतः वे आपके व्यापार मॉडल से अनजाने में जुड़े हुए हैं और इन्हें इस तरह माना जाना चाहिए।

Zend टेस्ट प्रलेखन शो एक लॉगिन फ़ंक्शन का उपयोग पूर्ण MVC परीक्षण करने के लिए कैसे के तल पर उदाहरण। संभवतः आप मॉडलों का परीक्षण करते समय भी ऐसा ही कर सकते हैं?

Answer 4

नहीं, यह नहीं होना चाहिए। भंडारण प्रकार, आपके व्यापार तर्क से अलग होना चाहिए। उदाहरण के लिए:

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

$User = Zend_Registry::get('User'); // User model object

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

यदि आप अपना डेटा प्राप्त करने के लिए एक से अधिक पथ ले रहे हैं, तो शायद यह आपके कंप्यूटर के बड़े होने पर कुछ समस्याएं पैदा करेगा।

OOP और स्तरित सिस्टम दृष्टिकोण सुझाव बनाई गई विशेष वस्तुओं और परतों के लिए है और सभी कोड में फैला दिया करने के लिए विशिष्ट कार्यों को रोकने साधारण चीजें रखने के लिए।

लेकिन फिर भी, जब तक आप लाभ नहीं देखते हैं तब तक आपको इसे बदलने की आवश्यकता नहीं है। ध्यान रखें कि कभी-कभी रीफैक्टरिंग सब कुछ भविष्यवाणी करने की कोशिश करने से अधिक कुशल होती है।