क्या आवेदन की व्यावसायिक परत सत्र वस्तु तक पहुंचने में सक्षम होनी चाहिए?

Question

कहें कि आपके पास 3 परतें हैं: UI, व्यवसाय, डेटा।

क्या व्यापार परत को सत्रों तक पहुंचने की आवश्यकता है तो क्या खराब डिजाइन का संकेत है? इसके बारे में कुछ सही नहीं लगता है। विशेष रूप से वेब ऐप के अनुरूप बनाए रखने के लिए कोई दिशानिर्देश हैं?

मैं उपयोग ग # 2.0 .net

Answer 1

मेरी भावना यह है कि व्यापार परत सत्र डेटा पहुंच को रखने का एकमात्र स्थान है क्योंकि यह वास्तव में आपके तर्क का हिस्सा है। यदि आप इसे प्रस्तुति परत में सेंकते हैं, तो यदि आप बदलते हैं कि वह डेटा कहां संग्रहीत किया जाता है (कहता है, अब आप सत्र स्थिति का उपयोग नहीं करना चाहते हैं), तो परिवर्तन करना अधिक कठिन है।

मैं सत्र डेटा के सभी डेटा के लिए क्या करूँगा, मैं उस डेटा की पुनर्प्राप्ति को समाहित करने के लिए एक कक्षा तैयार करूंगा। यह भविष्य में बदलाव की अनुमति देगा।

संपादित करें: यूआई का उपयोग केवल निम्नलिखित करने के लिए किया जाना चाहिए: 1. व्यापार परत पर कॉल करें। 2. उपयोगकर्ता (संदेश और घटनाओं) के साथ बातचीत करें। 3. स्क्रीन पर दृश्य वस्तु का उपयोग करें।

मैंने लोगों को डेटा परत के हिस्से के रूप में सत्र डेटा पहुंच पर विचार किया है, और यह अर्थपूर्ण है, और यह डेटा परत पर विचार करने पर निर्भर करता है।

Answer 2

मेरे लिए अजीब खुशबू। हो सकता है कि आपको सत्र और किसी अन्य राज्य की जानकारी का प्रबंधन करने के लिए प्रेजेंटेशन लेयर की आवश्यकता हो?

Answer 3

यदि आप सूचीबद्ध तीन परतों को रखते हैं, तो 'बिजनेस' परत सत्र वस्तुओं से निपटने के लिए सबसे उपयुक्त होगी।

चूंकि किसी सत्र में किसी भी वास्तविक व्यापार तर्क के साथ एप्लिकेशन को जोड़ने के लिए वास्तविक ढांचे के साथ अधिक सत्र करना पड़ता है, इसलिए आप एक नियंत्रण परत बनाना चाहते हैं जो सत्र ऑब्जेक्ट से डेटा को व्यवसाय डेटा इनपुट में व्यापार परत में अनुवादित करती है।

Answer 4

मुझे लगता है कि व्यापार तर्क प्रस्तुति विकल्प से बंधे नहीं होना चाहिए, और यदि सत्र उस स्तर में रहता है तो यह बंधेगा।

Answer 5

मैं सत्र के अनावश्यक उपयोग पर विचार सामान्य रूप में एक कोड गंध हो सकता है, अक्सर querystrings, कुकीज़ और viewstate lighterweight कर रहे हैं और बेहतर 'विषय-क्षेत्र'

एक व्यवसाय स्तरीय में सत्र भूमिका के रूप में है, यह क्या वास्तु पर निर्भर करता है गुरु आप इस समय पढ़ रहे हैं। यदि व्यापार तर्क स्तर यूआई से स्वतंत्र कोड के लिए एक जगह है, तो सत्र व्यवसाय स्तर में पेश करने की बात नहीं है।

उदाहरण के लिए, एक कंसोल ऐप में, एक एएसपी.नेट वेब ऐप, एक विंडोज सेवा, और एक विंडोज़ फॉर्म ऐप - केवल एएसपी.नेट में सत्र है।

यह कहा गया कि, एकाधिक यूआई का समर्थन करने में सक्षम होने के कारण एक अत्यधिक अतिरंजित विशेषता है और यह अनुमान लगाने के लिए सही दूरदर्शिता नहीं लेता है कि क्या आप कभी भी अपने ऐप को एक अलग उपयोगकर्ता इंटरफ़ेस पर पोर्ट कर देंगे। यदि आप अत्यधिक आश्वस्त हैं कि आपका तर्क केवल एएसपी.NET ऐप में ही और हमेशा के लिए चलाएगा, तो यह ठीक है।

एक अपवाद इकाई परीक्षण होगा। nnit परीक्षण धावक एक अलग यूआई का गठन करते हैं और अनुरोध, प्रतिक्रिया, सत्र, आवेदन इत्यादि को अनुकरण करना मुश्किल है

Answer 6

नहीं। यदि आपके पास "नियंत्रक" परत थी, तो आपको वहां पहुंचानी चाहिए। सत्र से आपको जो चाहिए उसे प्राप्त करें और इसे अपनी व्यावसायिक परत पर सौंप दें।

Answer 7

मुझे लगता है कि यह उपयोग पर निर्भर करता है, लेकिन हाँ, हम हर समय हमारे व्यापार परत से सत्र तक पहुंचते हैं। यहां एक "शुद्धता बनाम वास्तविकता" तर्क भी है।

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

protected virtual string GetConnectionString() 
{ 
string connectionString; 
string connectionStringSource; 

//In app.config? 
if (ConfigurationManager.AppSettings[_ConnectionStringName] != null && 
    ConfigurationManager.AppSettings[_ConnectionStringName] != "") 
{ 
    connectionString = ConfigurationManager.AppSettings[_ConnectionStringName]; 
    connectionStringSource = "Config settings"; 
} 
//Nope? Check Session 
else if (null != HttpContext.Current && null != HttpContext.Current.Session && 
    null != HttpContext.Current.Session[_ConnectionStringName]) 
{ 
    connectionString = (string)HttpContext.Current.Session[_ConnectionStringName]; 
    connectionStringSource = "Session"; 
} 
//Nope? Check Thread 
else if (null != System.Threading.Thread.GetData(
     System.Threading.Thread.GetNamedDataSlot(_ConnectionStringName))) 
{ 
    connectionString = (string)System.Threading.Thread.GetData(
      System.Threading.Thread.GetNamedDataSlot(_ConnectionStringName)); 
    connectionStringSource = "ThreadLocal"; 
} 
else 
{ 
    throw new ApplicationException("Can't find a connection string"); 
} 

if (debugLogging) 
    log.DebugFormat("Connection String '{0}' found in {1}", connectionString, 
      connectionStringSource); 

return connectionString; 
} 

Answer 8

व्यापार परत से सत्र को एक्सेस करना निश्चित रूप से एक कोड गंध है।

यदि आपको बताए गए व्यवसाय परत को 'स्विच' करने की आवश्यकता है, तो आपकी प्रस्तुति परत या नियंत्रक सभी को सत्र चर के बारे में चिंता करने की आवश्यकता है।

उदाहरण के लिए, आप एक सत्र चर के लिए ऑब्जेक्ट्स के एक सेट का उपयोग करना चाहते हैं और दूसरे चर के लिए एक और सेट का उपयोग करना चाहते हैं। आपका नियंत्रक सेवा परत को कॉल कर सकता है और चर में पास हो सकता है। सेवा परत फिर उचित व्यावसायिक वस्तु वापस कर देगी।

आपकी व्यावसायिक परत में सत्र के बारे में कुछ भी नहीं पता है कि आपके प्रेजेंटेशन लेयर के पास कोई व्यवसाय नहीं है कि आप डीबी से कैसे जुड़ रहे हैं।

Answer 9

सत्र ऑब्जेक्ट एक विशिष्ट UI कार्यान्वयन से जुड़ा हुआ है, इसलिए आपके व्यवसाय की परत आपके सत्र में मृत्यु हो गई है।

प्लस, शायद आप अपनी व्यावसायिक परत को यूनिट-टेस्ट करने में सक्षम होना चाहिए - यदि सत्र में निर्भरताएं हैं तो आप ऐसा कैसे करेंगे?

Answer 10

श्वास।

व्यापक आम सहमति नहीं होगी; व्यापार परत और नियंत्रक/वेब परत को अलग-अलग बनाए रखा जाना चाहिए, क्योंकि वे अलग-अलग चिंताओं हैं।

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

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

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

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

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

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