मैं इकाई की रूपरेखा के लिए एक सामान्य भंडार लिख रहा हूँ और करने के लिए के रूप में उलझन में क्या इन कॉल के बीच अंतर कर रहे हैं हूँ:.CreateObjectSet <T>, .Set <T>, और .reateQuery <T> के बीच अंतर।
ObjectContext.CreateObjectSet<T>
ObjectContext.CreateQuery<T>
DbContext.Set<T>
मैं एक सामान्य भंडार है कि दोनों पहले .edmx फाइलों के साथ ही कोड से उत्पन्न संदर्भ का समर्थन करता है चाहता हूँ
public abstract class EntityRepository<TClass>
where TClass : class, new()
{
//private readonly TContext _context;
private readonly ObjectSet<TClass> _objectSet;
protected EntityRepository(IObjectContextAdapter context)
{
_objectSet = context.ObjectContext.CreateObjectSet<TClass>();
}
protected EntityRepository(ObjectContext context)
{
_objectSet = context.CreateObjectSet<TClass>();
}
public ObjectSet<TClass> Query()
{
return _objectSet;
}
}
उदाहरण मुझे लगता है मैं सभी 3 इस्तेमाल किया देखा है ऑनलाइन देखा है, क्या उन दोनों के बीच वास्तविक मतभेद है: DbContext, इसलिए मैं इस मिल गया है? क्या एक बेहतर प्रदर्शन के रूप में है? मुझे पता है कि आप सभी 3 विधियों का उपयोग कर संदर्भों के खिलाफ LINQ क्वेरी लिख सकते हैं।
तो इनमें से प्रत्येक के लिए डेटाबेस के विरुद्ध क्वेरी चलाने पर वास्तव में कोई प्रदर्शन अंतर नहीं है? मेरे मामले में जब मेरा रिपोजिटरी वास्तविक संदर्भ संग्रहीत नहीं कर रहा है, तो क्या आप कहेंगे कि ऑब्जेक्टसेट चुनने का सही मार्ग है, इसलिए मैं इसके साथ सभी सीआरयूडी संचालन कर सकता हूं? – SventoryMang
मूल रूप से, और ऑब्जेक्टसेट: ऑब्जेक्टQuery । चाहे आप एक या दूसरे का उपयोग करके अपनी क्वेरी बनाते हैं, क्वेरी निष्पादन को प्रभावित नहीं करता है। CreateQuery की तुलना में CreateObjectSet पर कॉल में न्यूनतम ओवरहेड है (हम कुछ मेटाडाटा लुकअप करते हैं) लेकिन मुझे आश्चर्य होगा कि अगर इस ओवरहेड के असली दुनिया में कोई प्रभावशाली प्रभाव पड़ा तो मुझे आश्चर्य होगा। DbContext API पर सेट का अपूर्णता अन्य तरीकों से वास्तव में एक पतली परत है। इसका कोई महत्वपूर्ण प्रभाव नहीं होना चाहिए, और पूरी तरह से डीबीकॉन्टेक्स्ट एपीआई का उपयोग करना बहुत आसान और आसान है। –
divega