सलाह एक नौसिखिया के लिए के बारे में एन-टीयर आवेदन

Question

ठीक है लोगों को, यहाँ ya'll के लिए एक और एक है। मैंने विषय पर कुछ पढ़ा है और सामान्य सलाह यह है कि एन-स्तरीय ऐप्स का उद्देश्य सार कार्यक्षमता के बीच परतों के लिए है। तो, यह पर आधारित है, एक एन-स्तरीय अनुप्रयोग में नियमित रूप से मॉडल है:

Data Access -> Business Layer -> Presentation

जब से मैं एक .NET डेवलपर हूं मैंने सोचा था कि कई ग्राहक प्रकार (सिल्वरलाइट, वेब अनुप्रयोग के साथ एकीकरण को बढ़ाने के लिए या यहां तक ​​कि WinForms क्लाइंट) मुझे डब्ल्यूसीएफ (विंडोज कम्युनिकेशन फाउंडेशन) का उपयोग व्यावसायिक परत पर डेटा सेवाओं के रूप में करना चाहिए ताकि ग्राहक इसके प्रकार के बावजूद इसे संवाद कर सकें। इसके अलावा, मैं एक ओआरएम के रूप में NHibernate का एक बड़ा प्रशंसक हूं। ,

Data Access (NHibernate) -> Business Layer (WCF) -> Presentation (WPF, ASP.NET, WinForms

ठीक है ताकि सेटअप है: तो मेरी संरचना इस प्रकार है। मैं इस तरह के दृष्टिकोण में कुल नौसिखिया हूं, इसलिए मैंने सोचा कि मैं यहां इस सेटअप पर सलाह के लिए अनुरोध कर सकता हूं। इसके अलावा, मैं वीएस समाधान में इसे कैसे सेट अप करने के बारे में बहुत उलझन में हूं, मैं अलग-अलग परियोजनाओं में परतों को अलग करना चाहता हूं, लेकिन डेटा ऑब्जेक्ट्स (जैसे ग्राहक, ऑर्डर इत्यादि) के अमूर्तता के बारे में क्या? क्या मैं एक अलग पुस्तकालय में डालता हूं? और डब्ल्यूसीएफ के बारे में क्या? मुझे पता है कि तार पर डेटा कक्षाओं को क्लाइंट में स्थानांतरित करने के लिए प्रोग्रामर का पाप है। इसे हासिल करने का पेशेवर तरीका क्या है?

धन्यवाद, किसी भी सलाह की बहुत सराहना की जाएगी।

Answer 1

यह लक्ष्य पर काफी अधिक है। एन-टियर एन-लेयर की तुलना में थोड़ा अधिक जटिल है, और यह पूछकर विपरीत किया जा सकता है, "क्या आपकी परतें वास्तव में अलग-अलग भौतिक सर्वर पर रह रही हैं?"

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

यदि आप प्रेजेंटेशन लेयर एक ही सर्वर पर हैं, तो आपके एएसपी.नेट या विनफॉर्म ऐप्स की तुलना में डब्लूसीएफ सेवाओं के माध्यम से बीएलएल के साथ संवाद करना चाह सकता है।

Microsoft Patterns & Practices - Application Architecture Guide पर पढ़ें।

आपकी डोमेन ऑब्जेक्ट्स को आम तौर पर आपके डोमेन मॉडल में अपने स्वयं के असेंबली में रहना चाहिए। Microsoft Framework Design Guidelines के अनुसार, यह उसके अनुसार अपनी परियोजना विधानसभाओं नाम के लिए अच्छा अभ्यास है:।।

[कम्पनी] [ProductOrComponent] [...]

मैं नाम-दूरी के इस प्रारूप की तरह होता है और आम तौर पर उपयोग करें:

।।।।

मैं:

[कम्पनी] [उत्पाद] [लेयर] [उप-परत] [...]

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

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

आपके डेटा ऑब्जेक्ट को तार पर स्थानांतरित करने के लिए ... मुझे लगता है कि आप अपने ओआरएम से कक्षाओं का मतलब है। (डोमेन मॉडल) आप इसे आम तौर पर बुरी आदत मानते हैं। समाधान डाटा-ट्रांसफर ऑब्जेक्ट्स का उपयोग कर रहा है। आप मेरे पास एक तस्वीर से देख सकते हैं। लाइब्रेरी के लिए। यदि आप ऑटोमैपर जैसे टूल का उपयोग करने में सक्षम हैं, तो मैं इसके लिए सब कुछ कर रहा हूं, हालांकि, आपके समाधान में डीटीओ जोड़ने से इसकी जटिलता और रख-रखाव आता है। मेरा मानना ​​है कि डिनो एस्पोजिटो ने इस विषय पर एक अच्छा लेख लिखा था। इसे आपके लिए ढूंढने की कोशिश करेगा।

उम्मीद है कि इससे मदद मिलती है।

---

[संपादित करें]

मैं नोट करना चाहिए, मैं nHibernate की क्षमताओं के साथ अपरिचित हूँ। उस ओआरएम का उपयोग करने के लिए बेहतर समाधान हो सकते हैं। मैंने केवल एंटिटी फ्रेमवर्क के साथ काम किया है।

---

[संपादित करें 2]

बाहर चेक डिनो एस्पोसिटो के - The Pros and Cons of Data Transfer Objects