प्रस्तावना
उम्मीद है कि यह स्पष्ट है, लेकिन ... नीचे दिए गए नामस्थानों में, आप प्रतिस्थापित करेंगे MyCompanyऔर MyProjectआपकी कंपनी और परियोजना के वास्तविक नामों के साथ।
DTOs
मैं सभी परतों में एक ही डीटीओ कक्षाओं का उपयोग करने की सलाह दूंगा। इस तरह रखरखाव के कम अंक। मैं आमतौर पर उन्हें एक MyCompany.MyProject.Modelsनामस्थान के तहत , उसी नाम के अपने वीएस प्रोजेक्ट में डाल देता हूं । और मैं आमतौर पर वास्तविक दुनिया की इकाई के नाम पर उन्हें नाम देता हूं जिसका वे प्रतिनिधित्व करते हैं। (आदर्श रूप से, डेटाबेस टेबल एक ही नाम का भी उपयोग करते हैं, लेकिन कभी-कभी यह स्कीमा को थोड़ा अलग तरीके से सेट करने के लिए समझ में आता है।)
उदाहरण: Person, Address,Product
निर्भरताएँ: कोई नहीं (मानक .NET या सहायक पुस्तकालयों के अलावा)
दाल
यहाँ मेरी व्यक्तिगत प्राथमिकता डीटीओ कक्षाओं से मेल खाते हुए डीएएल वर्गों के एक-एक-एक सेट का उपयोग करना है, लेकिन एक MyCompany.MyProject.DataAccessनेमस्पेस / प्रोजेक्ट में। Engineसंघर्षों से बचने के लिए यहाँ वर्ग के नाम एक प्रत्यय के साथ समाप्त होते हैं । (यदि आप उस शब्द को पसंद नहीं करते हैं, तो एक DataAccessप्रत्यय भी ठीक काम करेगा। बस आप जो भी चुनते हैं उसके अनुरूप हो।) प्रत्येक वर्ग डेटाबेस को मारते हुए सरलतम सीआरयूडी विकल्प प्रदान करता है, जो अधिकांश इनपुट मापदंडों और वापसी प्रकारों के लिए डीटीओ कक्षाओं का उपयोग करता है (अंदर Listजब एक से अधिक एक जेनेरिक हों , जैसे, एक Find()विधि से वापसी )।
उदाहरण: PersonEngine, AddressEngine,ProductEngine
निर्भरता: MyCompany.MyProject.Models
बाल / BLL
यहां एक-के-लिए-एक मैपिंग भी, लेकिन एक MyCompany.MyProject.Logicनेमस्पेस / प्रोजेक्ट में, और एक Logicप्रत्यय प्राप्त करने वाली कक्षाओं के साथ । यह एकमात्र परत होनी चाहिए जो डीएएल को बुलाती है! यहां कक्षाएं अक्सर डीएएल के लिए एक सरल पास-थ्रू होती हैं, लेकिन यदि और जब व्यावसायिक नियमों को लागू करने की आवश्यकता होती है, तो इसके लिए यह जगह है।
उदाहरण: PersonLogic, AddressLogic,ProductLogic
निर्भरता: MyCompany.MyProject.Models,MyCompany.MyProject.DataAccess
एपीआई
यदि कोई वेब सेवा API लेयर है, तो मैं उसी वन-फॉर-वन अप्रोच का उपयोग करता हूं, लेकिन MyCompany.MyProject.WebApiनेमस्पेस / प्रोजेक्ट में, Servicesक्लास प्रत्यय के रूप में। (जब तक आप ASP.NET वेब API का उपयोग नहीं कर रहे हैं, उस स्थिति में आप Controllerइसके बजाय निश्चित रूप से प्रत्यय का उपयोग करेंगे )।
उदाहरण: PersonServices, AddressServices,ProductServices
निर्भरता: MyCompany.MyProject.Models, MyCompany.MyProject.Logic(इस बाईपास कभी नहीं दाल सीधे फोन करके!)
व्यापार तर्क पर एक अवलोकन
ऐसा लगता है कि लोगों के लिए BAL / BLL को छोड़ना अधिक आम हो गया है, और इसके बजाय एक या एक से अधिक परतों में व्यावसायिक तर्क को लागू करना, जहाँ भी यह सबसे अधिक समझ में आता है। यदि आप ऐसा करते हैं, तो बस यह निश्चित होना चाहिए कि (1) सभी एप्लिकेशन कोड व्यावसायिक तर्क के साथ परत (ओं) से गुजरते हैं, और (2) यह स्पष्ट और / या अच्छी तरह से प्रलेखित है जहां प्रत्येक विशेष व्यापार नियम लागू किया गया है। यदि संदेह है, तो घर पर यह कोशिश मत करो।
एंटरप्राइज-लेवल आर्किटेक्चर पर एक अंतिम नोट
यदि आप एक बड़ी कंपनी, या अन्य स्थिति में हैं जहां एक ही डेटाबेस टेबल को कई अनुप्रयोगों में साझा किया जाता है, तो मैं MyProjectऊपर दिए गए नामस्थान / परियोजनाओं से भाग को छोड़ने की सिफारिश करूंगा । इस तरह से उन परतों को कई फ्रंट-एंड एप्लिकेशन (और विंडोज सर्विसेज जैसी बैक-द-सी-दृश्य उपयोगिताओं) द्वारा साझा किया जा सकता है। लेकिन यह केवल तभी करें जब आपके पास मजबूत क्रॉस-टीम संचार हो और पूरी तरह से स्वचालित पुन: परीक्षण करना हो !!! अन्यथा, एक टीम के साझा कोर घटक में बदलाव से किसी अन्य टीम के आवेदन के टूटने की संभावना है।