कक्षाओं के लिए इस प्रकार के डिज़ाइन को आप कैसे वर्गीकृत करेंगे?

Question

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

क्या यह गलत है? क्या यह ओओपी विरोधी है?

User.cs 

public class User 
{ 

    public string Username { get; set; } 
    public string Password { get; set; } 
} 


Users.cs 


public class Users 
{ 
    public static User LoadUser(int userID) 
    { 
      DBProvider db = new DBProvider(); 
      return dp.LoadUser(userID); 

     } 

} 

Answer 1

मैं इसे डोमेन ऑब्जेक्ट या व्यावसायिक ऑब्जेक्ट के रूप में वर्गीकृत करूंगा। इस तरह के डिजाइन का एक लाभ यह है कि यह किसी भी व्यावसायिक तर्क के मॉडल अज्ञेयवादी रखता है और उन्हें विभिन्न प्रकार के वातावरण में पुन: उपयोग किया जा सकता है।

दूसरी कक्षा को डीएओ (डेटा एक्सेस ऑब्जेक्ट) के रूप में वर्गीकृत किया जा सकता है।

यह पैटर्न बिल्कुल एंटी-ओप नहीं है और इसका व्यापक रूप से उपयोग किया जाता है।

Answer 2

मुझे लगता है कि आप domain model और data-access object लागू कर रहे हैं। यह एक अच्छा विचार है।

Answer 3

जबकि आपकी उपयोगकर्ता.cs कक्षा domain transfer object की तरफ उधार दे रही है, तो User.cs क्लास अनिवार्य रूप से है जहां आप data-access objects के भीतर व्यवसाय नियम लागू कर सकते हैं।

आप नामस्थानों के साथ अपने वर्गों के नामकरण सम्मेलन के बारे में सोचना चाह सकते हैं। जब मैं user.cs को देखता हूं, तो मुझे लगता है कि यह अनिवार्य रूप से उपयोगकर्ताओं की सूची के साथ काम करने के लिए एक वर्ग होगा।

एक और विकल्प Active Record Pattern पर देखना होगा, जो आपके द्वारा बनाए गए दो वर्गों को जोड़ देगा।

User.cs 

public class User 
{ 
    public string Username { get; set; } 
    public string Password { get; set; } 

    public User(int userID) 
    { 
     //data connection 
     //get records 
     this.Username = datarecord["username"]; 
     this.Password = datarecord["password"]; 
    } 
} 

Answer 4

ऐसा लगता है कि यह repository pattern यह एक तेजी से सामान्य पैटर्न प्रतीत हो रहा है और Rob Conery's Storefront उदाहरण Asp.Net MVC अनुप्रयोग में प्रभावित करते हैं महान करने के लिए प्रयोग किया जाता है हो सकता है।

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

Answer 5

यह किसी भी अर्थ में वास्तव में ऑब्जेक्ट-ओरिएंटेड नहीं है, क्योंकि ऑब्जेक्ट कुछ भी नहीं है बल्कि डेटा चिपकने वाला डेटा है। यह नहीं कि यह एक भयानक बात है।

Answer 6

प्रथम श्रेणी एंटी-ओओपी है क्योंकि इसमें व्यवहार के बिना डेटा है, anemic domain model का एक विशिष्ट उदाहरण है। यह उन लोगों के लिए विशिष्ट है जो ओओ भाषा में प्रक्रियात्मक प्रोग्रामिंग करते हैं।

हालांकि, इस बात पर भरोसा है कि क्या यह डीबी एक्सेस लॉजिक को डोमेन मॉडल (सक्रिय रिकॉर्ड पैटर्न) में या अपने कोड में एक अलग वर्ग (डेटा एक्सेस ऑब्जेक्ट पैटर्न) में डालने के बाद समझ में आता है, क्योंकि डीबी एक्सेस एक अलग तकनीकी चिंता है जिसे डोमेन मॉडल के साथ निकटता से जोड़ा जाना चाहिए।