छोटे/मध्यम परियोजनाओं के लिए एएसपी.नेट एमवीसी, निबर्ननेट और रिपोजिटरी

मैं इस समय एक छोटी एएसपी.नेट एमवीसी परियोजना पर काम कर रहा हूं।
मैं एक एमएस एसक्यूएल सर्वर डेटाबेस पर बने रहने के लिए निबर्ननेट को लागू करने की कोशिश कर रहा हूं। डीडीडी और इंटरनेट पर मिलने वाली अन्य परियोजनाओं का अध्ययन करने में लंबे समय तक खर्च करने के बाद मैंने रिपोजिटरी पैटर्न के लिए जाने का फैसला किया है। अब मुझे एक दुविधा का सामना करना पड़ रहा है।
क्या मुझे वास्तव में निनबर्ननेट का उपयोग करते समय एक भंडार की आवश्यकता है?
बेहतर नहीं होगा एक सेवा लेयर (मैं इस समय एक सेवा परत नहीं है) जो Nhinbernate ऐसे ही कई बार कुछ लिखने के लिए टाल साथ सूचना का आदान के लिए:छोटे/मध्यम परियोजनाओं के लिए एएसपी.नेट एमवीसी, निबर्ननेट और रिपोजिटरी

public Domain.Reminder GetById(Guid Code) 
{ 
    return (_session.Get<Domain.Reminder>(Code)); 
} 

public Domain.Reminder LoadById(Guid Code) 
{ 
    return (_session.Load<Domain.Reminder>(Code)); 
} 

public bool Save(Domain.Reminder Reminder) 
{ 
    _session.SaveOrUpdate(Reminder); 
    return (true); 
} 

public bool Delete(Domain.Reminder Reminder) 
{ 
    _session.Delete(Reminder); 
    return (true); 
}

मैं एक पुराने पाया Ayende POST जो भंडार के खिलाफ है।
मुझे पता है कि इन विषयों के चारों ओर एक बड़ी बहस है और उत्तर हमेशा होता है ... निर्भर करता है, लेकिन ऐसा लगता है कि अवशोषण की बहुत सारी परतों के साथ चीजें अधिक जटिल और पालन करने में कठोर होती हैं।
क्या मैं गलत हूँ?

स्रोत

2011-01-21 LeftyX

बस एक छोटा सा नोट। कोई छोटी-छोटी परियोजना नहीं है, यह अब के लिए छोटा हो सकता है, लेकिन कल आपका प्रबंधक आपको एक और सुविधा, और फिर दूसरा, और दूसरा एक पूछेगा, और अंत में आपके पास एक छोटी-छोटी वास्तुकला के साथ एक विशाल परियोजना होगी । मैं वास्तव में 'बिग डिज़ाइन अप फ्रंट' की तरह नहीं हूं, लेकिन कभी-कभी आपको थोड़ा आगे सोचने की आवश्यकता होती है। – goenning

मैं आपसे पूरी तरह से सहमत हूं लेकिन वास्तव में, मैं रिपोजिटरी का उपयोग करने में लाभ नहीं देख सकता अगर इस तथ्य के लिए कि मैं भविष्य में निबर्ननेट का उपयोग नहीं कर सकता हूं। यह बहुत सारे काम पैदा कर रहा है जिसे मैं इस समय औचित्य नहीं दे सकता। – LeftyX

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

मैं उससे काफी सहमत हूं। अधिक काम के अलावा वास्तव में हासिल करने के लिए बहुत कुछ नहीं है।

स्रोत

2011-01-21 13:50:07

मुझे कबूल करना होगा कि यह वह जवाब है जिसे मैं सुनना चाहता था :-) – LeftyX

मुझे कुछ कारण मिले हैं कि आपको रिपोजिटरी/डीएओ/जो कुछ भी उपयोग करना चाहिए।

यूनिट परीक्षण। मैंने कभी भी एक सत्र को नकली/ठोकर लगाने की कोशिश नहीं की, लेकिन मैं कहूंगा कि यह एक रिपोजिटरी/डीएओ इंटरफेस को मजाक करने या छेड़छाड़ करने से बहुत अधिक जटिल होना चाहिए।
कोड का पुन: उपयोग। यदि आप अपनी क्वेरी को सीधे अपनी सेवाओं/नियंत्रकों में लिखते हैं तो आपको एक विशिष्ट क्वेरी का पुन: उपयोग करने की आवश्यकता होने पर इसे डुप्लिकेट करना समाप्त हो जाएगा। यदि आपके पास रिपोजिटरी में रैपर है, तो बस इसे विधि दें।
Single Responsibility Principle। अपने नियंत्रकों के आस-पास अपने प्रश्नों को फैलाने से आप इस सिद्धांत को तोड़ देते हैं।
NHibernate निर्भरता। ठीक है, ऐसा करना मुश्किल है, लेकिन अगर आपको अपना ओआरएम बदलना है, तो रिपोजिटरी इसे आसान बनाती है (देखो, यह आसान है, आसान नहीं है :))। या यहां तक कि जब आपको डेटाबेस से Microsoft सक्रिय निर्देशिका में उपयोगकर्ता डेटासोर्स को बदलने की आवश्यकता होती है, तो यह आसान होगा।

यह जानना है, कुछ और याद नहीं है।

स्रोत

2011-01-21 14:35:59 goenning

धन्यवाद ओनिंग। मैं अपने नियंत्रकों में प्रश्न लिखना नहीं चाहता बल्कि सेवा परत में लिखना चाहता हूं। मुझे लगता है कि कुछ व्यावसायिक तर्क भी लगाने के लिए यह एक अच्छी जगह है। यह यूआई में नहीं होगा और अगर मैं अपनी सेवा परत कहीं और प्लग करना चाहता हूं तो यह पुन: प्रयोज्य होगा। निषेध निर्भरता। खैर, हाँ, मैं सहमत हो सकता हूं लेकिन मुझे नहीं लगता कि यह जल्द ही होने जा रहा है और मुझे नहीं लगता कि यह एक भंडार बदलने से अलग है। फिर भी धन्यवाद। – LeftyX

1. यदि आप रेपो का मज़ाक उड़ाते हैं तो आप "ज्ञात स्थिरता" परीक्षण विरोधी पैटर्न का उपयोग कर रहे हैं। 2. कुछ भी नहीं कहता है कि आप अपनी सेवा परत में abstractions नहीं बना सकते हैं। यह पूरी तरह झूठा है। 3. बिलकुल नहीं। आप डीबी को किसी जगह पर कॉल करने जा रहे हैं। चाहे वह किसी सेवा या रेपो विधि कॉल या नियंत्रक का हिस्सा चाहे कोई फर्क नहीं पड़ता। अभी भी वही कोड। डीबी पूछताछ के लिए नियंत्रक अभी भी जिम्मेदार है। – jfar

@jfar 1. "ज्ञात स्थिरता" परीक्षण विरोधी पैटर्न क्या है? कभी नहीं सुना। मैं हमेशा अपने रेपॉजिटरीज़ का मज़ाक उड़ाता हूं। 2. अगर मैंने सही कहा है, तो आप एक ही डिजाइन को एक रिपोजिटरी के रूप में समाप्त कर देंगे लेकिन आप इसे कुछ और कहेंगे। इसका कोई उदाहरण मिला? मैं इस पर कुछ कोड देखना चाहता हूं। 3. नियंत्रक डीबी से पूछताछ के लिए ज़िम्मेदार नहीं है, उसे किसी और को ऐसा करने के लिए कहने की जरूरत है। उन्हें अनुरोध प्राप्त होता है और इसके आधार पर अन्य वर्गों में कार्यों का प्रतिनिधि होता है और अगला दृश्य चुनता है। – goenning

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

मैं गेट, लोड, सेव विधियों और विभिन्न मिलान-विधियों (लिंकक के लिए एक और मेरे डोमेन प्रश्नों के लिए एक) के साथ एक भंडार का उपयोग करता हूं।

पिछले विधि एक ICreateCritiera कार्यान्वयन स्वीकार करता है। नीचे इंटरफेस और इसका एक कार्यान्वयन है।

public interface ICreateCriteria<T> : ICreateCriteria 
{ 
    DetachedCriteria GetCriteria(); 
} 

public class ChallengesAvailableToRound : ICreateCriteria<Challenge> 
{ 
    private readonly Guid _roundId; 

    public ChallengesAvailableToRound(Round round) 
    { 
     _roundId = round.Id; 
    } 

    public DetachedCriteria GetCriteria() 
    { 
     var criteria = DetachedCriteria.For<Challenge>(). 
      CreateAlias("Event", "e"). 
      CreateAlias("e.Rounds", "rounds"). 
      Add(Restrictions.Eq("rounds.Id", _roundId)); 

     return criteria; 
    } 
}

इससे मुझे अपने वर्गों में प्रश्नों को तोड़ने और आसानी से अपने पूरे प्रोजेक्ट पर पुन: उपयोग करने की सुविधा मिलती है।

स्रोत

2011-01-21 15:43:11

मुझे आपके विचार केनी पसंद है। मैं इस पर काम करने की कोशिश करूंगा। धन्यवाद – LeftyX

केनी, मुझे लगता है कि आपका समाधान मेरे लिए काफी अच्छा है। धन्यवाद। – LeftyX

छोटे/मध्यम परियोजनाओं के लिए एएसपी.नेट एमवीसी, निबर्ननेट और रिपोजिटरी

उत्तर

संबंधित मुद्दे