2012-12-06 15 views
10

के लिए डिज़ाइन पैटर्न आपको लगता है कि यह होमवर्क है, क्योंकि मुझे खेद है। मैंने खोज की है लेकिन उचित जवाब नहीं मिला।डेटा एक्सेस लेयर

तो मेरे सवाल है:

मैं कई वर्गों है और प्रत्येक वर्ग को बचाने के लिए एक विधि है। तो मैंने डेटाबेस हैंडलिंग के लिए एक अलग वर्ग बनाया।

namespace HospitalMgt.Data 
{ 
    public static class DBConnection 
    { 
     public static string constr = "Data Source=ABD;Initial Catalog=HospitalMgt;User Id=sa;Password=123"; 
     public static SqlConnection con; 
     // public static SqlCommand com; 

     public static SqlConnection OpenConnection() 
     { 
      con= new SqlConnection(constr); 
      con.Open(); 
      return con; 
     } 

    } 
} 

हालांकि, मुझे नहीं लगता कि यह सभी कक्षाओं को डीबीसीनेक्शन कक्षा के साथ लागू करने के लिए उपयुक्त है।

मेरा प्रश्न:

  1. क्या डिजाइन पैटर्न इस समस्या को दूर करने के लिए अनुकूल है?
  2. क्या डीबीसी कनेक्शन को वर्ग के रूप में बनाने का अच्छा अभ्यास है? (या यह एक इंटरफ़ेस होना चाहिए)

मुझे फैक्टरी विधि का उपयोग करके डीए परतों के बारे में कुछ लेख मिले, लेकिन मेरे ज्ञान के अनुसार, यह पैटर्न मेरी स्थिति के अनुरूप नहीं है।

+0

रिपोजिटरी पैटर्न पर एक नज़र डालें, ऐसा लगता है जैसे यह आपकी मदद कर सकता है। – BenjaminPaul

+0

यदि आपके कोड में उपयोगकर्ता आईडी और पासवर्ड असली हैं, तो आपको उन्हें तुरंत छिपाना चाहिए। –

+0

क्या आप सिंगलटन बनाने की कोशिश कर रहे हैं? यदि हां, तो आप इसे गलत कर रहे हैं। –

उत्तर

10

आम तौर पर, अगर मैं किसी भी मौजूदा ढांचे का उपयोग नहीं कर सकते हैं, मैं दोनों भंडार और सक्रिय पैटर्न का उपयोग करें:

यहाँ इसके बारे में एक अच्छा लेख है।

सादगी के लिए, आप केवल रिपोजिटरी पैटर्न का उपयोग कर सकते हैं। मैं सामान्य रूप से इस तरह इसे परिभाषित:

// Define a generic repository interface 
public interface IRepository<Key, E> where E:IEntity<Key>>{ 
    void Add(E entity); 
    void AddRange(IEnumerable<E> entities); 
    IEntity<Key> Get(Key key); 
    IEnumerable<E> GetRange(IEnumerable<Key> keys); 
    IEnumerable<E> GetAll(); 
    // ..., Update, Delete methods 
} 

// Create an abstract class that will encapsulate the generic code 
public abstract class Repository<K, E> where E:IEntity<K>>:IRepository<K, E>{ 

    protected Repository(/*parameter you may need to implement the generic methods, like a ConnectionFactory, table name, entity type for casts, etc */){} 

    public override void Insert(IEntity<Key> entity){ 
     // do the insert, treat exceptions accordingly and encapsulate them in your own and more concise Exceptions, etc 
    } 
    // ... 
} 

// Create the entities classes, one for each table, that will represent a row of that table 
public class Car: IEntity<String>{/* Properties */} 

// Create a specific repository for each table 
// If the table have a composed key, just create a class representing it 
public CarRepository: Repository<String, Car>{ 

    public CarRepository(){/* pass the base parameters */} 

    // offer here your specific operations to this table entity 
    public IEnumerable<Car> GetByOwner(PersonKey ownerKey){ 
     // do stuff 
    } 
} 

अब आप डेटाबेस में हेरफेर करने के लिए पर्याप्त उपकरण नहीं है, लेकिन अगर आप चाहते हैं, आप सक्रिय पैटर्न का उपयोग कर सकते हैं। एक साधारण उदाहरण:

public class Person:IEntity<PersonKey>{ 
    public PersonKey Key{get;} 
    public IEnumerable<Car> OwnedCars{ 
     get{ 
      CarRepository rep = DBSingletons.Cars; 
      return rep.GetByOwner(this.Key); 
     } 
     set{ 
      // do stuff 
     } 
    } 
} 

जाहिर है, जब अपने स्वयं के कार्यान्वयन कर रही है, तो आप खाते धागा सुरक्षा में लेन-देन की का उपयोग कर अच्छा कर रही है, विशेष रूप से विभिन्न इकाई खजाने भर में रखना चाहिए।

// simple example 
ITransaction t = TransactionFactory.GetNewTransaction(); 
t.begin(); 
try{ 
    // create person entity 
    personRepository.Add(person, t); 
    // create cars assigned to person 
    carRepository.AddRange(cars, t); 
    t.commit(); 
}catch(Exception){ 
    t.rollback(); 
} 

बस सुनिश्चित करें कि आप वास्तव में के बाद से यह extremelly जटिल beeing समाप्त कर सकते हैं अपनी खुद की दाल बनाना चाहते हो, विशेष रूप से सबसे सामान्य समाधान विकसित करने की कोशिश।

+1

में देखता हूं क्या यह संकलित करता है? उदाहरण के लिए, सार्वजनिक इंटरफ़ेस आईआरपॉजिटरी <कुंजी, ई जहां ई: आईएनएनटीटी > सार्वजनिक इंटरफ़ेस होना चाहिए आईआरपॉजिटरी जहां ई: आईएनटीटी (कृपया < > पर ध्यान दें), है ना? कुल मिलाकर, महान उदाहरण हालांकि !! – crunchy

+0

टिप के लिए धन्यवाद! मेरा मानना ​​है कि मैंने इस कोड को मेरे सिर से नोटपैड ++ में बनाया है, इसलिए मैं उस समय इसका परीक्षण नहीं कर सका! फिक्स जोड़ा गया! –

5

मुझे सुझाव है कि एक ओआरएम, एंटिटी फ्रेमवर्क या एनएचबेर्नेट का उपयोग करने से सुझाव मिलेगा। तो आपको डीबी संदर्भ के बारे में चिंता करने या SQL कथन बनाने की आवश्यकता नहीं है।

+0

thanx ... लेकिन मुझे उनके पीछे सिद्धांत सीखना पसंद है – DevT

+1

इसके साथ कोई चिंता नहीं है। लेकिन रिपॉजिटरी को डिज़ाइन करने के तरीके को जानने के लिए एनएचबीर्नेट को स्रोत कोड क्यों न पढ़ें। या सक्रिय रिकॉर्ड देखें, एनएचबीर्नेट से पढ़ने के लिए यह आसान है। या बस इसे @ सर्गी के रूप में Google ने सबसे अधिक संभवतः किया है (मैंने आपको +1 @ sergey दिया था)। –

+0

ठीक है .... thanx फिर से ... – DevT

4

सबसे पहले, मैं आपको लेख Design Patterns for Data Persistence by Jeremy Miller अनुशंसा करना चाहता हूं।

कुछ डेटा का उपयोग परत पैटर्न होते हैं:

  1. Active record pattern (wiki, Detailed info)।
  2. Repository pattern (Detailed info)।
+0

मैं उन्हें देखूँगा ... आपकी मदद के लिए thanx – DevT

+0

@TilT, आपका स्वागत है! –

2

मेरा सुझाव है कि आप इन सभी आम परिचालनों के लिए एक रिपोजिटरीबेस का उपयोग करें। यदि आप डेटा एक्सेस के लिए ओआरएम का उपयोग करने का निर्णय लेते हैं तो जेनेरिक टाइप रिपोजिटरी के आधार पर रिपॉजिटरीज के कार्यान्वयन में सोचना अच्छा होता है।

http://lostechies.com/jimmybogard/2009/09/03/ddd-repository-implementation-patterns/

+0

thanx मैं इस – DevT

1

यह बहुत पुराना है लेकिन अभी इस प्रश्न के आसपास आया है और मेरे विचार पोस्ट करने का विरोध नहीं कर सका।

मुझे RepositoryUnitOfWork के साथ कुछ मूल ओआरएम अच्छा दृष्टिकोण है। यह ज्यादातर मुद्दों को कम करता है।

उपरोक्त लिंक में उल्लिखित यूओडब्ल्यू को रिपोजिटरी में इंजेक्शन दिया जा सकता है। इससे उपयोग की लचीलापन बढ़ जाती है। इसके अलावा, सभी डीबी संचार कोड एक ही स्थान पर केंद्रीकृत है। उदाहरण पूर्ण नहीं है लेकिन स्टार्टअप पॉइंट है।

उपरोक्त लिंक में उल्लिखित रिपोजिटरी पैटर्न वास्तव में एक सामान्य आधार वर्ग है। आप अपने प्रत्येक कंक्रीट रिपोजिटरी के लिए नई कक्षा बना सकते हैं जो इससे निकलती है।

सामान्य भंडार को एक विरोधी पैटर्न माना जाता है; इंटरनेट पर बहुत से लेख हैं जो इसे समझाते हैं।

जेनेरिक रिपोजिटरी विरोधी पैटर्न क्यों है?

  1. एक भंडार डोमेन का मॉडल का एक हिस्सा है, और यह डोमेन सामान्य नहीं है।
    • प्रत्येक इकाई को हटाया नहीं जा सकता है।
    • प्रत्येक इकाई को जोड़ा नहीं जा सकता
    • प्रत्येक इकाई में एक भंडार नहीं है।
    • क्वेरीज जंगली रूप से भिन्न होते हैं; भंडार एपीआई इकाई के रूप में अद्वितीय के रूप में अद्वितीय हो जाता है।
    • GetById() के लिए, पहचानकर्ता प्रकार अलग-अलग हो सकते हैं।
    • विशिष्ट फ़ील्ड (डीएमएल) को अपडेट करना संभव नहीं है।
  2. जेनेरिक क्वेरी तंत्र एक ओआरएम की ज़िम्मेदारी है।
    • अधिकांश ओआरएम जेनेरिक रिपोजिटरी के साथ मिलकर एक कार्यान्वयन का पर्दाफाश करते हैं।
    • रेपॉजिटरीज ओआरएम द्वारा उजागर जेनेरिक क्वेरी तंत्र का उपयोग कर इकाइयों के लिए विशिष्ट प्रश्नों को लागू करना चाहिए।
  3. समग्र कुंजी के साथ काम करना संभव नहीं है।
  4. यह वैसे भी सेवाओं में डीएएल तर्क को लीक करता है।
    • यदि आप सेवा परत से पैरामीटर की आवश्यकता के रूप में स्वीकार करते हैं तो प्रमाणित मानदंड। यदि यह ओआरएम विशिष्ट वर्ग है, तो यह सेवाओं में ओआरएम लीक करता है।

समाधान:

  1. एक सामान्य भंडार है कि एक ठोस भंडार से लपेटा जाता है है।इस तरह आप सार्वजनिक इंटरफ़ेस को नियंत्रित कर सकते हैं लेकिन अभी भी जेनेरिक रिपोजिटरी से आने वाले कोड-पुन: उपयोग का लाभ है।
  2. एक सामान्य भंडार का उपयोग करें, लेकिन विरासत के बजाय संरचना का उपयोग करें और इसे अनुबंध के रूप में डोमेन में बेनकाब न करें।