ब्रेकिंग BLL BLL और दाल (डेटा एक्सेस परत) से (व्यापार तर्क परत)

Question

कृपया नीचे दिए गए कोड देखें:

Imports Microsoft.VisualBasic 

Public Class PersonBLL 
    Private Name As String 
    Private Age As Integer 

    Dim objPersonDAL As New PersonDAL 
    Dim objPerson As Person 

    Public Sub getPersonByID() 
     objPerson = objPersonDAL.getPersonByID() 
     MsgBox(objPerson.Name) 
    End Sub 
End Class 

Public Class PersonDAL 
    Private Name As String 
    Private Age As Integer 

    Public Function getPersonByID() As Person 
     'Connect to database and get Person. Return a person object 
     Dim p1 As New Person 
     p1.Name = "Ian" 
     p1.Age = 30 
     Return p1 
    End Function 
End Class 

Public Class Person 
    Private _Name As String 
    Private _Age As Integer 

    Public Property Name() As String 
     Get 
      Return _Name 
     End Get 
     Set(ByVal value As String) 
      _Name = value 
     End Set 
    End Property 

    Public Property Age() As Integer 
     Get 
      Return _Age 
     End Get 
     Set(ByVal value As Integer) 
      _Age = value 
     End Set 
    End Property 
End Class 

PersonBLL PersonDAL कॉल करता है और एक व्यक्ति वस्तु देता है। क्या यह सही दृष्टिकोण है? यानी मैंने एक सतत कक्षा की पहचान की है और डेटा तक पहुंचने और व्यक्ति वस्तु को वापस करने के लिए एक समारोह के साथ एक संबंधित डीएएल कक्षा बनाई है।

एक टिप्पणी है जिसमें कहा गया है कि यह प्रश्न "व्यक्तिपरक" है। मैं इससे सहमत हु। मुझे एहसास है कि डिजाइन परियोजना की आवश्यकताओं पर निर्भर करता है। क्या सोलिड (एकल जिम्मेदारी इत्यादि) जैसे डीएएल को डिजाइन करने के लिए दस्तावेज किए गए कोई सिद्धांत हैं

Answer 1

हां, आपका प्रश्न परतों को तर्क में अलग करने का एक बहुत साफ तरीका दिखाता है। PersonBLL कक्षा व्यावसायिक परत का हिस्सा होगी, PersonDAL कक्षा डेटा एक्सेस परत का हिस्सा होगी, और Person कक्षा डेटा स्थानांतरण ऑब्जेक्ट्स (डीटीओ) परत का हिस्सा होगी। यह आपकी परतों को अलग करने का एक बहुत ही आम तरीका है जो कई स्थितियों में अच्छी तरह से काम करता है।

मेरी केवल सिफारिशों होगा:

• आप, अपने स्वयं के नामस्थान में प्रत्येक परत रखना चाहिए नहीं तो भी अपने स्वयं के वर्ग पुस्तकालय परियोजनाओं।
• आपको व्यवसाय परत से एक संदेश बॉक्स नहीं दिखाना चाहिए। मुझे लगता है कि आपने इसे केवल प्रदर्शन के साधन के रूप में किया है, लेकिन बस मामले में, मैंने सोचा कि मुझे इसका जिक्र करना चाहिए। एक संदेश बॉक्स दिखा रहा है यूआई परत का हिस्सा होना चाहिए। उदाहरण के लिए, यदि आप विंडोज सेवा या वेब सेवा से PersonBLL.getPersonByID पर कॉल कर रहे थे, तो एक संदेश बॉक्स दिखाकर पूरी तरह से अनुचित होगा।
• आम तौर पर, सभी विधियां पास्कलकेस हैं, ऊंट नहीं। कुछ लोग निजी तरीके ऊंट मामले बनाना पसंद करते हैं, लेकिन निश्चित रूप से सार्वजनिक तरीकों को ऊंट का मामला नहीं होना चाहिए।
• व्यापार ऑब्जेक्ट में डेटा एक्सेस ऑब्जेक्ट को इंजेक्ट करने के लिए निर्भरता-इंजेक्शन तकनीकों (डीआई) का उपयोग करने पर विचार करें।

  Public Class BusinessFactory 
      Public Function NewPersonBusiness() As IPersonBusiness 
       Return New PersonBusiness(New PersonDataAccess()) 
      End Function 
  End Class 
  
  Public Class PersonBusiness 
      Implements IPersonBusiness 
  
      Public Sub New(personDataAccess As IPersonDataAccess) 
       _personDataAccess = personDataAccess 
      End Sub 
  
      Private _personDataAccess As IPersonDataAccess 
  
      Public Function GetPersonByID() As PersonDto Implements IPersonBusiness.GetPersonByID 
       Return _personDataAccess.GetPersonByID() 
      End Sub 
  End Class 
  
  Public Interface IPersonBusiness 
      Function GetPersonByID() As PersonDto 
  End Interface 
  
  Public Interface IPersonDataAccess 
      Function GetPersonById() As PersonDto 
  End Interface 
  
  Public Class PersonDto 
      Private _name As String 
      Private _age As Integer 
  
      Public Property Name() As String 
       Get 
        Return _name 
       End Get 
       Set(ByVal value As String) 
        _name = value 
       End Set 
      End Property 
  
      Public Property Age() As Integer 
       Get 
        Return _age 
       End Get 
       Set(ByVal value As Integer) 
        _age = value 
       End Set 
      End Property 
  End Class 
  

  कर रहा इस तरह से कई लाभ हैं:

निर्भरता इंजेक्शन

यहाँ कैसे डि तकनीक के साथ ऐसा करने का एक उदाहरण है। आपके पास एकाधिक अदला-बदली डेटा एक्सेस लेयर कार्यान्वयन हो सकते हैं, इसलिए यह अधिक लचीला है। साथ ही, जब आप यूनिट को बिजनेस क्लास का परीक्षण करना चाहते हैं तो आप नकली डेटा एक्सेस ऑब्जेक्ट इंजेक्ट कर सकते हैं। डी डिज़ाइन कई जाल से बचाता है जो छोटी गाड़ी, स्पेगेटी कोड का कारण बनता है।

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

क्यों इंटरफेस का उपयोग कर, बल्कि वर्गों की तुलना में, अपने निर्भरता के लिए दो कारण हैं महत्वपूर्ण है:

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

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

2. आप अपनी निर्भरता के बारे में अधिक तकनीकी रूप से ईमानदार हैं। हकीकत में, आप वास्तव में यह नहीं कह रहे हैं कि आपकी निर्भरता वास्तव में PersonDataAccess कक्षा का एक उदाहरण है। वास्तविकता में, आपकी निर्भरता वह वस्तु होती है जो वही सार्वजनिक इंटरफ़ेस होती है। कक्षा के लिए पूछकर, आप यह कह रहे हैं कि आपको एक विशेष कार्यान्वयन की आवश्यकता है, जो एक झूठ है। आप इसे ठीक तरह से डिजाइन किया गया है, तो आप केवल एक ही इंटरफ़ेस किया जा रहा है के बारे में परवाह है, इसलिए केवल इंटरफेस के लिए पूछ करके, आप निर्दिष्ट करते हैं आप निर्दिष्ट करने के लिए :)