3-परत आर्किटेक्चर - परतों के बीच डेटा पास करना

Question

3-परत को कार्यान्वित करने की कोशिश कर रहा है (नहीं: मैं बस अपनी परियोजना को एक मशीन पर तार्किक रूप से अलग करना चाहता हूं) आर्किटेक्चर मुझे इतने सारे अलग-अलग दृष्टिकोण मिल गए हैं कि मैं उलझन में हूं WinForms ऐप में इसे बनाने के लिए सबसे अच्छा तरीका क्या है (यदि कोई है)।

अब मुझे कोई संदेह ही के बारे में 3 परतें कि इस परियोजना में उपस्थित होना चाहिए है:

• यूआई (प्रस्तुति परत)
• BLL (व्यापार तर्क परत)
• दाल (डेटा पहुंच लेयर)

यूआई में मैंने सभी WinForms डाल दिए। ऑब्जेक्ट को नियंत्रण से डेटा भरने के लिए कुछ तर्क होना चाहिए और इसे बीएलएल परत में पास करना होगा।

में दाल मैं ADO.NET का उपयोग कर, की तरह वर्गों और डेटा जोड़तोड़ के लिए तरीकों को रखना चाहता हूँ:

public class OrderDAL 
{ 
    public OrderDAL() 
    { 
    } 

    public int Add(Order order) 
    { 
     //...add order to database 
    } 

    public int Update(Order order) 
    { 
     //...update order in database 
    } 

    //...etc. 
} 

समस्या

BLL और सवाल के साथ है - मैं डाटा ट्रांसफर करने के लिए ऑब्जेक्ट्स का उपयोग करना चाहिए परतों के बीच डेटा पास करें, या मुझे पूरी कक्षा उत्तीर्ण करनी चाहिए?

public class Order 
{ 
    public int Id { get; set; } 
    public DateTime Date { get; set; } 
    public string Number { get; set; } 
    public string CustomerName { get; set; } 

    public Order() 
    { 
    } 
} 

और तर्क BLL में अलग रख:

मैं डीटीओ उपयोग करने के लिए चुनते हैं, तो मैं अतिरिक्त सामान्य वर्ग, Order, यूआई, BLL और दाल के लिए कि संदर्भ बनाने के लिए है :

public class OrderBLL 
{ 
    public OrderBLL() 
    { 
    } 

    public int Add(Order order) 
    { 
     OrderDAL orderDAL = new OrderDAL(); 
     return orderDAL.Add(order); 
    } 

    public int Update(Order order) 
    { 
     OrderDAL orderDAL = new OrderDAL(); 
     return orderDAL.Update(order); 
    } 

    //...etc. 
} 

यह दृष्टिकोण, विभिन्न नामों के तहत, दूसरों के बीच प्रयोग किया जाता है: here या here।
दूसरी तरफ, कुछ "बुद्धिमान लोग" और उनके अनुयायियों (जैसे here) इसे Anemic Domain Model पर कॉल करें और शिकायत करें कि यह एक खराब डिज़ाइन और एंटी-पैटर्न है जिसका उपयोग नहीं किया जाना चाहिए।

पेशेवरों:

• डीटीओ आसानी से डिजाइन द्वारा डाटाबेस तालिका प्रतिनिधित्व करने के लिए कर सकते हैं,
• यह प्रकाश और स्पष्ट है, केवल डेटाबेस के लिए आवश्यक फ़ील्ड हैं,
• दाल संदर्भित करने के लिए नहीं है BLL,

विपक्ष:

• विरोधी पैटर्न (डरावना लगता है, पी), OOP के
• उल्लंघन (तरीकों से अलग गुण),
• क्योंकि तर्क अलग वर्ग में है, इसे बनाए रखने जब कुछ बदल जाता है और अधिक कठिन हो सकता है।

तो, विपरीत दृष्टिकोण here की तरह, परतों के बीच पूरी वस्तु पारित करने के लिए है: कोई डीटीओ, बस BLL कि तरह लग रही:

public class Order 
{ 
    public int Id { get; set; } 
    public DateTime Date { get; set; } 
    public string Number { get; set; } 
    public string CustomerName { get; set; } 

    public Order() 
    { 
    } 

    public int Add() 
    { 
     OrderDAL orderDAL = new OrderDAL(); 
     return orderDAL.Add(this); 
    } 

    public int Update(Order order) 
    { 
     OrderDAL orderDAL = new OrderDAL(); 
     return orderDAL.Update(order); 
    } 
} 

पेशेवरों:

• यह ओओपी नियमों (मुझे लगता है;) के बाद, एक अच्छी तरह से encapsulated वस्तु है)।
• दोनों तर्क और गुण एक ही स्थान पर हैं, बनाए रखने और डीबग करने में आसान हैं।

विपक्ष:

• वस्तु का उपयोग करने, दाल को संदर्भित करने के BLL (? कि कैसे 3-स्तरीय परत क्या करना चाहिए, ऐसा नहीं है नहीं है) है।
• कक्षा में कुछ फ़ील्ड हो सकते हैं जिनका उपयोग डेटाबेस में नहीं किया जाता है, साथ ही डेटाबेस (जैसे आईडी) के कुछ फ़ील्ड "असली जीवन" ऑब्जेक्ट का प्रतिनिधित्व नहीं करते हैं।

तो, ऐसा लगता है कि जो भी मैं चुनता हूं, मैं कुछ नियमों का उल्लंघन करूंगा। तब बेहतर तरीका क्या है, मुझे कौन सा चयन करना चाहिए? शायद मुझे कोई अन्य दृष्टिकोण नहीं मिला है?

Answer 1

मुझे डीटीओ पसंद नहीं हैं, क्योंकि उनका मतलब है कि दो या दो मूल्य वाले दोहरी पदानुक्रम बनाना है।

मुझे मॉडल की वस्तुओं को अपने स्वयं के दृढ़ता के लिए जिम्मेदार बनाने का विचार पसंद नहीं है। मैं एक अलग दृढ़ता परत पसंद करते हैं। क्यूं कर? आदर्श वस्तुओं को हमेशा उपयोगी होने की आवश्यकता नहीं है। व्यापार तर्क और कार्यक्षमता दृढ़ता के लिए ऑर्थोगोनल हैं।

यदि आपके पास दो परतें हैं तो एक तरफ निर्भरता ग्राफ रखना संभव है: दृढ़ता मॉडल के बारे में जानती है, लेकिन मॉडल दृढ़ता के बारे में नहीं जानता है। यदि मॉडल ऑब्जेक्ट दृढ़ता के लिए ज़िम्मेदार हैं तो आप चक्रीय निर्भरता के साथ समाप्त हो जाते हैं। आप बिना किसी दृढ़ता के मॉडल मॉडल का परीक्षण या उपयोग नहीं कर सकते।

मेरी सलाह? डीटीओ मत करो। एक अलग दृढ़ता परत तोड़ो।