मैं अपने एन-लेयर आर्किटेक्चर का पुनर्मूल्यांकन करने की कोशिश कर रहा हूं और आपके अनुभवों के आधार पर कुछ सुझाव प्राप्त करना पसंद करूंगा। यहां हमारी सामान्य .NET एन-लेयर (कभी-कभी एन-स्तरीय) डिज़ाइन है।एन-लेयर व्यवसाय/सेवा परत डिजाइन
Project.UI
Project.Services
Project.Business
Project.Model
Project.DataAccess
DataAccess आम तौर पर Entity Framework 4 और Repository वर्गों के होते हैं। मैं टेबल के लिए भंडार रखने से बचने के लिए Aggregate Root अवधारणा का पालन करने का प्रयास करता हूं, मेरे अनुभव में किए गए आसान से कहा जाता है। मेरे पास रिपोजिटरीज और टेबल्स के बीच ~ 70% मैच होता है।
मॉडल में आमतौर पर मेरी Entity Framework 4 इकाइयां होती हैं, मैं सफलतापूर्वक स्व-ट्रैकिंग ईएफ इकाइयों का उपयोग कर रहा हूं।
व्यवसाय मैं सबसे ज्यादा संघर्ष करता हूं। मेरे पास आमतौर पर प्रत्येक Repository के लिए Manager कक्षा होती है। इस श्रेणी में विधियां शामिल होंगी .एड() जो रिपोजिटरी को अग्रेषित करने से पहले व्यावसायिक सत्यापन करेगा। जोड़ें()।
सेवाएं, आम तौर पर मैं केवल इसे लागू कर दूंगा यदि वास्तव में मैं एक वेब सेवा आधारित समाधान बनाना चाहता हूं। इस परत को डीटीओ और संस्थाओं के बीच मार्शलिंग अनुरोध/प्रतिक्रियाओं के साथ काम किया जाएगा। और सबसे महत्वपूर्ण रूप से अधिक coarse grained इंटरफेस प्रदान करते हैं। उदाहरण के लिए एक TradingService.SubmitTrade() है, जो वास्तव में एक facade एक व्यापार लेनदेन जो AccountManager.ValidateCash(), OrderManager.SubmitOrder(), शामिल हो सकता है के लिए है आदि
चिंताएं
मेरे व्यापार परत बहुत इकाई है केंद्रित, वास्तव में यह इकाइयों और भंडार के बीच गोंद है, बीच में सत्यापन के साथ। मैंने कई डिज़ाइन देखे हैं जहां सर्विस लेयर रिपोजिटरी का संदर्भ रखता है (संक्षेप में "व्यापार परत" को छोड़कर)। संक्षेप में यह मेरी व्यावसायिक परत के समान उद्देश्य प्रदान करता है, यह सत्यापन करता है, हालांकि इसकी 'ज़िम्मेदारी (और नामकरण) एक उच्च स्तर, अधिक मोटे अनाज वाले व्यापार लेनदेन है। TradingService.submitTrade() के ऊपर दिए गए उदाहरण का उपयोग किसी भी व्यवसाय प्रबंधक वर्गों को नहीं दिया जाएगा, यह स्वयं आवश्यक भंडारों से पूछताछ करेगा, सभी सत्यापन आदि करेगा।
मुझे अपने डिजाइन को इस तरह से पसंद है कि मैं एक व्यवसाय का पुन: उपयोग कर सकता हूं कई सेवा कॉल में परत विधि, हालांकि मुझे इस तथ्य से नफरत है कि प्रत्येक भंडार के लिए मेरे पास एक मिलान करने वाला व्यवसाय परत प्रबंधक है, जो अतिरिक्त काम करता है। शायद समाधान बिजनेस लेयर स्तर पर समूह का एक अलग प्रकार है? उदाहरण के लिए ContactManager (नोट मेरे पास "संपर्क" इकाई प्रकार नहीं है) जैसे लॉजिकल मैनेजर क्लास में फोनमैनेजर और ईमेल मैनेजर (नोट मेरे पास फोन इकाइयां और ईमेल इकाइयां हैं) के व्यक्तिगत प्रबंधक वर्गों को गठबंधन करें। ContactManager.GetPhones() और ContactManager.GetEmail(), आदि जैसे विधियों के साथ
मुझे लगता है कि मैं कुछ भी सोच रहा हूं कि दूसरों को कैसे व्यवस्थित करना है और जिम्मेदारियों का प्रतिनिधित्व करना है, भले ही उनके पास सेवा परत, व्यापार परत, दोनों आदि हों। ओआरएम संदर्भ संदर्भ, आदि
क्या आपके पास कभी भी एक सेवा कॉल है जो कई व्यवसाय प्रबंधक वर्गों को फैलाती है? दूसरे शब्दों में, आपका सेवा इंटरफ़ेस व्यवसाय प्रबंधकों की तुलना में और भी मोटे अनाज हो सकता है। उदाहरण के लिए ContactService.CreateUser(), UserManager.CreateUser() और ContactManager.AddEmail(), और ContactManager.AddPhone(), आदि को प्रतिनिधि (एक मुखौटा के रूप में सेवा) प्रतिनिधि करेगा। भले ही हमने संपर्क मैनेजर में ईमेल और फ़ोन से संबंधित तर्क को समूहीकृत किया हो , फोन रिपोजिटरी और ईमेल रिपोजिटरी रखने में कुछ भी गलत नहीं है। ऐसा लगता है कि Repositories प्रबंधकों की तरह "तार्किक" नहीं हो सकता है। – e36M3
शायद ही कभी, लेकिन ऐसा हुआ है। मैं व्यवसाय की परत में जितना तर्क कर सकता हूं उतना तर्क रखना पसंद करता हूं, क्योंकि इससे कोई मुझे उपलब्ध कराता है अगर कोई मेरे पास बाद में आता है और एक ऐसा वेबपृष्ठ चाहता है जो सेवा करता है (और हाँ, ऐसा होता है)। वेबपृष्ठ उसी व्यापार परत तर्क को कॉल कर सकता है जो सेवा करता है, बल्कि सेवा को कॉल करता है (वे मेरे मामले में एक ही सर्वर पर हैं)। तो इस तरह के मामले में मैं क्या करूँगा एक व्यापार प्रबंधक विधि है जो स्वयं अन्य व्यावसायिक प्रबंधकों का उपयोग कर सकती है। हालांकि, सादगी में वास्तविक लाभ होने पर मैं इसे टालने का प्रयास करता हूं। – Tridus
मुझे पता है कि आपका क्या मतलब है, मैं अपने प्रबंधकों को रचनाकार के माध्यम से आवश्यक भंडार प्रदान करने के लिए DI का उपयोग करता हूं। एक प्रबंधक को एक और प्रबंधक बनाने के लिए प्रबंधकों को डी कंटेनर से अवगत होना आवश्यक होगा। हालांकि इसके बिना ऐसा लगता है कि कभी-कभी मैं कॉपी और पेस्ट करके तर्क को डुप्लिकेट कर रहा हूं। उदाहरण के लिए DataEntryManager.EnterPrice() और FileManager.UploadPriceFile()। आप कल्पना कर सकते हैं कि "मूल्य फ़ाइल" को पार्स करने के बाद हमें कीमतें डालना होगा। मैं या तो उस तर्क के कुछ डुप्लिकेट कर सकता हूं या FileManager DataEntryManager का पुन: उपयोग कर सकता हूं। – e36M3