वे अमूर्त आधार वर्गों में बदल गए होंगे क्योंकि इंटरफेस को संस्करणित नहीं किया जा सकता है।

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

@ जेम्सएनके मैं देखता हूं। लेकिन चूंकि .NET Core एक नया API है और ADO.NET API लगभग एक दशक में काफी स्थिर है, क्या आपको लगता है कि यह अभी भी एक वैध चिंता का विषय है? साथ ही, डेटाबेस एक्सेस के बारे में मेरा अनुमान है कि वर्चुअल विधियों की लागत डेटाबेस एक्सेस की लागत से बौनी है।

@NickCraver , @roji , @FransBouma चूंकि आप लोगों को ADO.NET API में रुचि है, इस बारे में कुछ कहना है?

@YoungGah , क्या यह पीछा करने लायक है?

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

एक दूरस्थ डेटाबेस और प्रसंस्करण परिणामों पर एक क्वेरी निष्पादित करने की प्रक्रिया में, एक virtcall पर खो गए नैनोसेकंड नगण्य हैं। इसके अलावा, ADO.NET शुरुआत से ही इस प्रणाली का उपयोग करता है (इसलिए .NET में कई अन्य एपीआई करें) और किसी ने शिकायत नहीं की कि वर्चुअल विधि कॉल के कारण उनका डीबी कोड इतना धीमा है;)

मैं आपकी सूची में एसिंक विधियों को देख सकता हूं इसलिए मैं कुछ साल पहले अनुमान लगा रहा हूं कि एमएस आईडीबीकॉमैंड में एसिंक नहीं जोड़ सका। कौन जानता है कि कल क्या लाएगा जिसके लिए नए तरीकों या गुणों की आवश्यकता होगी।

इंटरफेस संस्करण नहीं है।

प्रदर्शन कुछ आभासी न बनाने का सिर्फ एक कारण है। शायद प्रत्यारोपण के लिए सतह क्षेत्र को कम करना? मैं एमएस में किसी को यह कहने दूँगा कि उन्होंने ऐसा क्यों नहीं करने का फैसला किया, मुझे ADO.NET के बारे में ज्यादा जानकारी नहीं है इसलिए मैं सिर्फ अनुमान लगा रहा हूं।

@JamesNK मुझे लगता है कि आपकी चिंताएँ मान्य हैं, लेकिन विचार करने के लिए 2 महत्वपूर्ण बिंदु हैं:

1. ADO.NET .NET 2.0 के बाद से काफी स्थिर रहा है, जो एक दशक बाद - हालांकि एसिंक एपीआई को बाद में जोड़ा गया था, इसने एपीआई के व्यवहार को नहीं बदला, बस एसिंक समकक्ष जोड़े - मुझे इसमें कोई बड़ा बदलाव नहीं दिख रहा है डेटाबेस ड्राइवर प्रतिमान कभी भी जल्द ही
2. CoreFx को एक अलग संस्करण का विचार माना जाता है, क्योंकि आप पुराने ऐप्स के लिए पिछले CLR को ही रख सकते हैं। इसलिए इंटरफ़ेस संस्करण के मुद्दों का यहाँ इतना प्रभाव नहीं होना चाहिए

यह भी विचार करें कि "लोकलहोस्ट" पर एक एसक्यूएल सर्वर भी एक खाली क्वेरी को जोड़ने और वापस करने के लिए कुछ एमएस पट्टे पर खर्च करेगा। व्यवहार में, रिलेशनल डेटाबेस के लिए अधिकांश _fast_ प्रश्न ~20ms लगते हैं।

वर्चुअल मेथड लुकअप में माइक्रोसेकंड को बचाने की तुलना में NSubstitute या Moq जैसे मानक टूल के साथ API को मॉक करने में सक्षम होना आज डेवलपर के लिए बहुत अधिक मूल्यवान है।

मुझे लगता है कि मेरी यहां बहुत मजबूत राय नहीं है, लेकिन यहां कुछ टिप्पणियां दी गई हैं:

• उपरोक्त से सहमत हैं कि वर्चुअल बनाम गैर-वर्चुअल को हटाना डेटाबेस एक्सेस के लिए एपीआई में नगण्य है
• बेस क्लास ADO.NET को कार्यान्वयन प्रदान करने की अनुमति देते हैं, मैं अनुमान लगा रहा हूं कि अधिकांश गैर-आभासी गैर-अमूर्त विधियों के बारे में हैं - ExecuteReader का अधिभार जो कमांडबेवियर को स्वीकार नहीं करता है, अधिभार के लिए CommandBehavior.Default पास करता है वैसा करता है। यदि आप इंटरफेस पर स्विच करते हैं, तो प्रत्येक प्रदाता को ठीक उसी बॉयलरप्लेट के साथ ExecuteReader() को लागू करना होगा ...
• मुझे यकीन नहीं है कि यह सभी प्रमुख मॉकिंग फ्रेमवर्क में मान्य है, लेकिन कम से कम Moq में बेस क्लास को मॉक करना उतना आसान नहीं है जितना कि यह एक इंटरफ़ेस है?

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

मैं @roji की हर बात से सहमत हूं।

@roji सिर्फ एक नोट, मैं आधार वर्गों को

परीक्षण के लिए, अगर मेरा एपीआई सही तरीकों को बुला रहा था, तो मुझे परीक्षण करने में बड़ी समस्याएं थीं। यह जांचने के लिए कि क्या ExecuteDataReader को उदाहरण के लिए सही पैरामीटर मिले हैं, आपको एक और संरक्षित विधि की जांच करनी चाहिए जिसे आंतरिक रूप से विभिन्न मापदंडों के साथ कहा जाता है। यह आदर्श से बहुत दूर है।

वर्तमान में, जब तक मैं गलत नहीं हूँ, ADO.NET API का मजाक उड़ाने वाला एकमात्र ढांचा MS Fakes फ्रेमवर्क है जो कॉल को इंटरसेप्ट करके बिल्कुल कुछ भी नकल कर सकता है। Moq और अन्य ऐसा नहीं कर सकते।

मुझे यह देखने में दिलचस्पी है कि क्या अन्य लोगों के समान मुद्दे थे।

@roji सिर्फ एक नोट, मैं आधार वर्गों को

क्षमा करें, मैंने इसे गलत समझा। उस स्थिति में, क्या आपका प्रस्ताव चीजों को कमोबेश वैसा ही नहीं रखता जैसा वे .NET में हैं (ऐसा नहीं है कि इसमें कुछ भी गलत है)?

परीक्षण के लिए, अगर मेरा एपीआई सही तरीकों को बुला रहा था, तो मुझे परीक्षण करने में बड़ी समस्याएं थीं। यह जांचने के लिए कि क्या ExecuteDataReader को उदाहरण के लिए सही पैरामीटर मिले हैं, आपको एक और संरक्षित विधि की जांच करनी चाहिए जिसे आंतरिक रूप से विभिन्न मापदंडों के साथ कहा जाता है। यह आदर्श से बहुत दूर है।

अगर मैं आपके परिदृश्य को समझता हूं (निश्चित नहीं), Moq का CallBase इस तरह के परिदृश्य के लिए उपयोगी है - डिफ़ॉल्ट कार्यान्वयन बेस क्लास से विरासत में मिला है

@roji

क्या आपका प्रस्ताव कमोबेश चीजों को .NET में रखने जैसा नहीं है (ऐसा नहीं है कि इसमें कुछ गलत है)?

बिल्कुल नहीं। इंटरफ़ेस API को .NET 1.0 में जोड़ा गया था और 2.0 को पदावनत कर दिया गया था। 2.0 के बाद से, संगतता के लिए इंटरफेस मौजूद हैं, लेकिन डेटा.कॉमन में ProviderFactory या अन्य वर्गों के लिए कोई इंटरफ़ेस नहीं है। एसिंक एपीआई या 2.0 या नए तरीकों के लिए भी कुछ भी नहीं है।

Moq केवल उन चीजों का मजाक उड़ा सकता है जो उपहास योग्य हैं। कुछ ऐसी विधि होनी चाहिए जो या तो आभासी या अमूर्त हो जिसे वह ओवरराइड कर सकता है, या एक संरक्षित विधि जिसे वह कॉल कर सकता है। वर्तमान एपीआई कुछ मामलों के लिए विधि प्रदान करता है, लेकिन उनमें से अधिकांश के लिए नहीं। ऐसी कई चीजें हैं जो आंतरिक, निजी और पहुंच से बाहर हैं जब तक कि आप प्रतिबिंब का उपयोग नहीं करते हैं। केवल एमएस फेक ही ऐसा कर सकते हैं क्योंकि यह संदर्भ को शिम से बदल देता है, लेकिन यह केवल वीएस एंटरप्राइज पर उपलब्ध है और ओपन सोर्स प्रोजेक्ट्स के लिए बेकार है।

ऐसा लगता है कि मेरे पास एक बहुत ही विशिष्ट मामला है, लेकिन निश्चित रूप से जिसने भी इस एपीआई का मजाक उड़ाने की कोशिश की, उसे इस मुद्दे का सामना करना पड़ा। बस Google, लगभग हर समाधान "विरासत इंटरफ़ेस एपीआई का मज़ाक उड़ाएं या एक रैपर बनाएं जिसे आप नकल कर सकते हैं" के साथ समाप्त होता है:

@nvivo ठीक है, अतिरिक्त विवरण के लिए धन्यवाद - मैं मानता हूं कि मैं ADO.NET का मज़ाक

जो बात मुझे समझ में नहीं आ रही है, वह यह है कि आप एपीआई के आंतरिक, निजी और अन्यथा पहुंच के तरीकों का मजाक क्यों उड़ाना चाहेंगे। क्या आपको सार्वजनिक तरीकों का मज़ाक नहीं उड़ाया जाना चाहिए जो सीधे आपके अपने आवेदन कोड पर उपलब्ध हैं (जिसे आप परीक्षण करने का प्रयास कर रहे हैं)? मुझे गैर-आभासी विधियों (जैसे 0-पैरामीटर ExecuteReader() अधिभार) के साथ समस्या दिखाई देती है, लेकिन यह देखते हुए कि ADO.NET में ये हमेशा (?) कुछ वर्चुअल अधिभार कहते हैं (जैसे ExecuteReader (CommandBehavior)), क्या कोई असली मुद्दा यहाँ?

बस अपनी समस्या परिदृश्य को समझने की कोशिश कर रहे हैं, क्या आप एक साधारण उदाहरण दे सकते हैं?

@nvivo वर्तमान में हमारे पास वर्जनिंग मुद्दे के कारण इंटरफेस लाने की कोई योजना नहीं है जो पहले से ही इस धागे पर कई लोगों द्वारा इंगित किया गया था। इंटरफेस के पीछे छूटने का अच्छा उदाहरण है जब .NET Framework 4.5 में async और स्ट्रीमिंग विधियों को जोड़ा गया था। जब हमने उन नई सुविधाओं को जोड़ा, तो हमने ध्यान से विस्तारित इंटरफेस पर ध्यान दिया। उस समय हमारे पास जो विकल्प थे, वे या तो इंटरफेसफूवी2 प्रदान करते थे या एसिन और स्ट्रीमिंग के लिए अलग इंटरफेस प्रदान करते थे। हम InterfaceFooV2 को नहीं जोड़ना चाहते थे क्योंकि हम यह अनुमान लगा सकते हैं कि हम भविष्य में और API जोड़ना चाहेंगे। प्रत्येक नई कार्यक्षमता के लिए अलग-अलग इंटरफेस जोड़ते रहें, यह भ्रमित करने वाला होगा क्योंकि वे मौजूदा इंटरफेस से बंधे नहीं हैं।

@roji मेरे पास ऐसे मामले थे जहां मैं यह सुनिश्चित करना चाहता हूं कि ExecuteReader का एक विशिष्ट अधिभार कहा गया था, न कि "कोई भी अधिभार"। यह ऐसी चीज है जो आपके पास केवल पुस्तकालयों में है, उपयोगकर्ता कोड पर नहीं।

@YoungGah जानकारी के लिए धन्यवाद। मैं इसे तब बंद कर रहा हूं।

क्या इस बदलाव के लिए जिम्मेदार लोगों को इसके प्रभाव का अंदाजा है? कोर ADO.NET इंटरफेस लगभग एक दशक से अधिक समय से हैं और डेटा एक्सेस अधिकांश व्यावसायिक ऐप्स का केंद्र है, मुझे यह समझने में परेशानी हो रही है कि कैसे जानबूझकर इतने सारे मौजूदा कोड बेस को तोड़ना सर्वोच्च प्राथमिकता नहीं है? ये .NET में कुछ सबसे महत्वपूर्ण उच्च-स्तरीय इंटरफेस हैं, इन ब्रेक को हटाकर प्रत्येक ADO .NET डेटा एक्सेस लाइब्रेरी और इसके परिणामस्वरूप प्रत्येक प्रोजेक्ट इसका उपयोग कर रहा है। उन्हें हटाने से एक कृत्रिम विखंडन पैदा होता है, जिससे निराशा और भ्रम पैदा होता है जो CoreCLR को अपनाने में बाधा उत्पन्न करेगा।

आप अभी भी संस्करण इंटरफेस कर सकते हैं और किसी भी नए एपीआई के बंद IDbCommand लिए एक्सटेंशन विधियों को जोड़कर उन्हें स्रोत संगत बना सकते हैं, उदाहरण के लिए:

public interface IDbCommand
{
    //...
}

public class DbCommand : IDbCommand
{
    void NewApi();
}

public static class DbCommandExtensions
{
    public static void NewApi(this IDbCommand cmd)
    {
        ((DbCommand)cmd).NewApi();
    }
}

DNX जारी होने के बाद कोर IDbCommand इंटरफ़ेस को कभी भी बदलना नहीं पड़ता है और आप ऊपर की रणनीति के साथ कार्यक्षमता जोड़ना जारी रख सकते हैं। आप बाद में भी (एक प्रमुख ब्रेकिंग संस्करण में) इन एक्सटेंशन को रोल अप कर सकते हैं और उन्हें कोर इंटरफ़ेस में मर्ज कर सकते हैं। किसी भी तरह से हमें कोर स्थिर ADO.NET इंटरफेस मिलता है जो मौजूदा कोड बेस के माइग्रेशन के लिए महत्वपूर्ण है और परिणामस्वरूप CoreCLR को अपनाने के लिए।

मुझे @davkean द्वारा कोर एडीओ .NET इंटरफेस को हटाने के प्रभाव के ठोस उदाहरण प्रदान करने के लिए कहा गया है। मैं कल्पना नहीं कर सकता कि इस परिवर्तन को मौजूदा .NET पारिस्थितिकी तंत्र पर पड़ने वाले अथाह प्रभाव का मूल्यांकन किए बिना माना गया था, लेकिन फिर यह भी किया गया है, इसलिए एक संभावना है कि इस पर विचार नहीं किया गया - जिसे मैं यहां मानने जा रहा हूं- इसमें नहीं था।

EF की .NET की डिफ़ॉल्ट ORM होने की भूमिका और बाजार हिस्सेदारी के एक बड़े हिस्से पर कब्जा करने में इसकी उत्कृष्ट सफलता के बावजूद, अभी भी .NET डेवलपर्स की एक बड़ी आबादी है जो इसके बजाय कई अलग-अलग कारणों से वैकल्पिक ORM का उपयोग करना पसंद करते हैं। जैसे कोरसीएलआर से संबंधित एक महत्वपूर्ण विशेषता यह है कि उनके पास मोनो/लिनक्स/ओएसएक्स पर चलने वाले प्रथम श्रेणी के समर्थन के साथ-साथ कई वैकल्पिक आरडीबीएमएस का समर्थन है। चूँकि CoreCLR Linux/OSX डेवलपर बाज़ार के लिए बहुत अधिक प्रयास कर रहा है, ऑल्ट RDBM के लिए जितना अधिक समर्थन होगा, उतना ही बेहतर होगा। माइक्रो ओआरएम को अपनाने वाले देवों की आबादी का एक अन्य महत्वपूर्ण गुण यह है कि उन्होंने एमएस इकोसिस्टम डिफॉल्ट्स के बाहर मूल्यांकन किया है ताकि वह ओआरएम चुन सकें जो उनके लिए सबसे उपयुक्त है। मैंने जो कुछ भी देखा है, उसमें सक्रिय .NET OSS (यानी एंटी-डार्क मैटर) देवों और माइक्रो ओआरएम को अपनाने वाले देवों के बीच एक उच्च सहसंबंध है, इसी तरह मैं उम्मीद करता हूं कि कोरसीएलआर के शुरुआती अपनाने वालों के साथ इसका उच्च संबंध होगा - जिसका प्रमुख मूल्य प्रस्ताव है ओएसएक्स/लिनक्स पर विकसित करने के लिए। ये कुछ कारण हैं कि इस तरह के मौलिक ब्रेकिंग डिज़ाइन विकल्प बनाते समय आपके निर्णय लेने में आसपास के .NET पारिस्थितिकी तंत्र को शामिल करना फायदेमंद क्यों होगा।

वैकल्पिक ओआरएम डाउनलोड

NuGet डाउनलोड पर एक सरसरी निगाह इस बात का संकेत देती है कि गैर-EF बाजार-शेयर कैसा दिखता है:

NHibernate - 1M+
डैपर - 1M+
ओआरएमलाइट - 500k+
सरल। डेटा - 300k+
पेटापोको - ~ 100k
एनपोको - 30k+

वास्तविक संख्या इससे कहीं अधिक है क्योंकि कई माइक्रो ओआरएम जैसे डैपर, मैसिव, पेटापोको, एनपोको, आदि को एक ही ड्रॉप-इन .cs में फिट करने के लिए डिज़ाइन किया गया था, इसलिए NuGet इसके वास्तविक उपयोग की रिपोर्ट नहीं कर रहा है। एलएलबीएलजेन प्रो जैसे बंद स्रोत ओआरएम भी हैं जिनके पास एक बड़ा उपयोगकर्ता आधार है लेकिन इसका उपयोग नुगेट द्वारा रिपोर्ट नहीं किया गया है, वैसे ही मुझे यकीन है कि मैंने कई अन्य ओआरएम को याद किया है जिन्हें मैं भूल गया/पता नहीं हूं।

वैकल्पिक ओआरएम पर प्रभाव

GitHub के लिए धन्यवाद, हम यह देखने के लिए एक त्वरित खोज कर सकते हैं कि कितनी अलग-अलग स्रोत फ़ाइलों में कोर है
इस परिवर्तन से प्रभावित IDbConnection , IDbCommand और IDataReader ADO .NET इंटरफेस:

नोट: ये परिणाम केवल स्रोत फ़ाइलें दिखाते हैं, टूटे हुए संदर्भों की वास्तविक संख्या बहुत अधिक है।

ग्राहक स्रोत कोड पर प्रभाव

इस परिवर्तन का वास्तविक प्रभाव इन ओआरएम का उपयोग करने वाली सभी परियोजनाओं पर निर्भर करता है।
दुर्भाग्य से प्रभाव आंतरिक कार्यान्वयन तक सीमित नहीं है क्योंकि यह ग्राहक को भी तोड़ता है
स्रोत कोड के रूप में कई माइक्रो ओआरएम ADO.NET इंटरफेस पर सिर्फ विस्तार विधियां हैं इसलिए क्लाइंट
कोड जैसा दिखता है:

IDbConnection db = ...

//Dapper
db.Query<Dog>("select Age = <strong i="49">@Age</strong>, Id = @Id", new { Age = (int?)null, Id = guid });

//OrmLite
db.Select<Author>(q => q.Name.StartsWith("A"));

विस्तार विधियों का उपयोग करने से एक एक्स्टेंसिबिलिटी विशेषता यह है कि ये ओआरएम "ओपन एंडेड" हैं और ग्राहक अपने स्वयं के प्रोजेक्ट में एक्सटेंशन विधियों को जोड़कर ओआरएम को अपने प्रथम श्रेणी के एपीआई के साथ बढ़ा सकते हैं - ये भी टूटा हुआ है।

स्पष्ट रूप से कोई भी स्रोत कोड जो IDbConnection आसपास से गुजरता है, अब भी CoreCLR पर काम करने से प्रतिबंधित है।

उदाहरण के लिए कोर ADO.NET इंटरफेस का उपयोग सर्विसस्टैक जैसे उच्च स्तरीय ढांचे में

सारांश

मैं व्यक्तिगत रूप से चकित हूं कि इन इंटरफेस के बिना कभी भी .NET में भविष्य बनने जा रहा था।
इंटरफ़ेस डिज़ाइन उद्देश्य-विशिष्ट द्वारा कई कार्यान्वयन की अनुमति देने के लिए हैं और ADO.NET एक है
.NET में सबसे महत्वपूर्ण "ओपन प्रोवाइडर मॉडल"। मुझे नहीं पता कि किन प्राथमिकताओं ने इन इंटरफेस को हटा दिया, लेकिन दोनों बड़े पैमाने पर मौजूदा .NET कोड बेस जो वैकल्पिक-ईएफ .NET पारिस्थितिकी तंत्र के साथ इन इंटरफेस पर भरोसा करते हैं, को बहुत अधिक प्राथमिकता दी जानी चाहिए। यह एक महत्वपूर्ण व्यवधान पैदा कर रहा है और मौजूदा .NET 4.x और CoreCLR दोनों प्लेटफार्मों का समर्थन करने के लिए आवश्यक एक प्रमुख बाधा है, जो अतिरिक्त जटिलता की एक गैर-तुच्छ राशि को मजबूर करता है जिसे इससे प्रभावित सभी मौजूदा कोड-बेस पर लागू किया जाना चाहिए।

वर्तमान धारणा यह है कि ADO.NET/CoreCLR को EF और SQL सर्वर के लिए प्रथम श्रेणी का समर्थन प्रदान करने के लिए फिर से डिज़ाइन किया जा रहा है, बाकी पारिस्थितिकी तंत्र की अवहेलना की जा रही है - इस तरह के गैर-पारदर्शी ब्रेकिंग निर्णय केवल इस स्टीरियोटाइप को फिर से लागू करने के लिए जाते हैं .

.NET टीम के पिछले सदस्य के रूप में (मैं अब रोसलिन पर काम करता हूं), मैं SQL और एंटिटी फ्रेमवर्क टीमों के साथ-साथ नए डेटा कॉमन के मूल डिजाइन में भारी रूप से शामिल था। मैं इस समय इसमें शामिल नहीं हूं, लेकिन मैं कुछ पृष्ठभूमि जोड़ सकता हूं ताकि कुछ बयानों को ठीक करने में मदद मिल सके जो मैं ट्विटर और ऊपर देख रहा हूं।

.NET कोर के लिए System.Data.Common का वर्तमान डिज़ाइन दिसंबर 2012 में शुरू हुआ, हमारे ओपन सोर्स से लगभग 2 साल पहले।

लक्ष्य:

• .NET कोर के लिए एक आधुनिक सतह क्षेत्र डिज़ाइन करें, जिसने अवधारणाओं के दोहराव को कम किया ( IDbConnection बनाम DbConnection ), भ्रम, गलतियाँ और लेयरिंग मुद्दे (डेटाकॉमन से विभाजित SqlClient, कोर एब्स्ट्रैक्शन से डेटासेट को विभाजित करें) .NET 1.0 से मूल डिजाइन। एक जिसे मौजूदा उपभोक्ताओं और _new_ डेवलपर्स दोनों द्वारा .NET फ्रेमवर्क में आसानी से उठाया जा सकता है।
• प्रदाताओं और उपभोक्ताओं को .NET कोर के विरुद्ध एकल बाइनरी/स्रोत बनाने में सक्षम करें, और फिर उसी बाइनरी को .NET फ्रेमवर्क पर चलाएं। ध्यान दें, उल्टा लक्ष्य नहीं था; .NET Framework बाइनरी/स्रोत लेने और .NET कोर पर कुछ बदलावों के बिना इसे चलाने में सक्षम होने के नाते।

चारों ओर फैलाई जा रही कुछ चीजों का सुधार:

• इंटरफेस के रूप में वे खड़े हैं संस्करण योग्य नहीं हैं। हम सदस्यों को इंटरफेस में नहीं जोड़ सकते हैं, और विस्तार विधियों के माध्यम से @mythz द्वारा प्रदान किए गए प्रस्ताव के लिए आवश्यक है कि प्रदाता वैसे भी सार आधार वर्गों से प्राप्त करें।
• System.Data.Common _has not_ प्रदाता मॉडल से दूर चले गए हैं। इंटरफेस हटा दिए गए थे क्योंकि वे एक विरासत .NET 1.0 अवधारणा थी जिसे .NET 2.0 में पेश किए गए सार आधार वर्गों द्वारा प्रतिस्थापित/डुप्लिकेट किया गया था। जिस समय हमने यह निर्णय लिया, प्रत्येक प्रदाता जिसे हम आधार वर्गों से प्राप्त कर सकते थे।
• इंटरफेस की तरह, बेस क्लास नकली हैं।
• हम समझ गए थे कि .NET 1.0 इंटरफेस का उपयोग करने वालों के लिए कुछ बदलावों की आवश्यकता होगी, हालांकि, बेस क्लास में जाने के लिए यह एक बहुत ही सरल पोर्ट है। उदाहरण के लिए, AutoMapper के लिए परिवर्तन की ये कुछ पंक्तियाँ देखें: (https://github.com/AutoMapper/AutoMapper.Data/blob/master/AutoMapper.Data/DataReaderMapper.cs#L14)।

कुछ ऐसा जिसे समझने में मुझे परेशानी हो रही है:

हम सदस्यों को इंटरफेस में नहीं जोड़ सकते

कोरसीएलआर इंटरफेस में सदस्यों को जोड़ना अभी तक ठीक नहीं है, उन्हें पूरी तरह से बाहर निकालना ठीक है?

विस्तार विधियों के माध्यम से @mythz द्वारा प्रदान किए गए उपरोक्त प्रस्ताव के लिए आवश्यक है कि प्रदाता वैसे भी सार आधार वर्गों से प्राप्त करें।

महत्वपूर्ण हिस्सा यह है कि इंटरफेस मौजूद हैं और स्रोत कोड की अनुमति देता है जो उन्हें संकलित करने के लिए संदर्भित करता है।

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

यह आधार वर्गों में जाने के लिए एक बहुत ही सरल बंदरगाह है।

इसे प्रत्येक स्रोत फ़ाइल पर जोड़ने की आवश्यकता है जो ADO.NET इंटरफेस का संदर्भ देती है, और ग्राहकों को कस्टम बिल्ड प्रतीकों के साथ अपना कोड डालने के लिए मजबूर करती है।

यहाँ पश्चगामी संगतता के लिए समान देखभाल प्रतीत नहीं होती है, लेकिन भविष्य में रिलीज़ में मौजूदा ग्राहकों को जानबूझकर तोड़ना एक विकल्प नहीं है (मुझे आश्चर्य है कि इसे ADO .NET के बहुत बड़े बाजार हिस्से के साथ भी माना जाता है)। हम मौजूदा 4.x ग्राहकों को नहीं तोड़ सकते हैं और फिर भी हमें CoreCLR का समर्थन करने के लिए कहा जा रहा है - तो यह मौजूदा 4.x पुस्तकालयों को कहां छोड़ता है जो मौजूदा पिछड़े संगतता को बनाए रखना चाहते हैं और CoreCLR का भी समर्थन करते हैं? क्या हमें डॉक्स/उदाहरणों की भी नकल करनी चाहिए?

कोरसीएलआर इंटरफेस में सदस्यों को जोड़ना अभी तक ठीक नहीं है, उन्हें पूरी तरह से बाहर निकालना ठीक है?

.NET कोर में सतह क्षेत्र को .NET फ्रेमवर्क के साथ बाइनरी संगत होना चाहिए ताकि प्रथम पक्ष और तृतीय पक्ष .NET कोर के विरुद्ध निर्माण कर सकें, और .NET फ्रेमवर्क में बदलाव किए बिना पोर्टेबिलिटी चला सकें। इंटरफेस में सदस्यों को जोड़ने से इसका उल्लंघन होता है, क्योंकि जब वे .NET फ्रेमवर्क पर चलते हैं तो उन सदस्यों के उपभोक्ता विफल हो जाते हैं।

मैं इन इंटरफेस को हटाने या जोड़ने के लिए बहस नहीं कर रहा हूं, मैं सिर्फ कुछ पृष्ठभूमि जोड़ना चाहता हूं कि डिजाइन कहां समाप्त हुआ। मैं @YoungGah और @saurabh500 सहित मौजूदा मालिकों को दूंगा ।

केवल थ्रेड को संक्षेप में प्रस्तुत करने के लिए, जिस कारण से आप मानते हैं कि Microsoft को इन इंटरफेस को पोर्ट करना चाहिए, वह है पारिस्थितिकी तंत्र को उनके .NET फ्रेमवर्क कार्यान्वयन को बनाए रखते हुए आसानी से .NET कोर को पोर्ट करने में सक्षम बनाना?

अपने .NET फ्रेमवर्क कार्यान्वयन को बनाए रखते हुए, पारिस्थितिकी तंत्र को आसानी से .NET कोर में पोर्ट करने में सक्षम बनाना है?

हां।

केवल थ्रेड को संक्षेप में प्रस्तुत करने के लिए, जिस कारण से आप मानते हैं कि Microsoft को इन इंटरफेस को पोर्ट करना चाहिए, वह है पारिस्थितिकी तंत्र को उनके .NET फ्रेमवर्क कार्यान्वयन को बनाए रखते हुए आसानी से .NET कोर को पोर्ट करने में सक्षम बनाना?

हां। यदि मैं अपने कोडबेस (एलएलबीएलजेन प्रो) को कोरएफएक्स में पोर्ट करता हूं तो बाहरी एपीआई अब टूट गए हैं: मुझे 2 एपिस का खुलासा करना होगा या अपने सभी उपयोगकर्ताओं के लिए मौजूदा कोडबेस को तोड़ना होगा।

आप लोगों के लिए यह ठीक हो सकता है कि आप हमारा सामान तोड़ दें क्योंकि आपको दर्द महसूस नहीं होता, हम करते हैं। यह मेरे द्वारा ठीक नहीं है: मुझे या तो एक कसाई कोड आधार के साथ रहना है और 2 एपीआई बनाए रखना है जो एक ही काम करते हैं, या मेरे उपयोगकर्ताओं के कोड को तोड़ते हैं क्योंकि आपने सोचा था कि यह ठीक था।

मुझे यह भी नहीं पता कि इंटरफेस संस्करण क्यों नहीं है, यह सिर्फ एक इंटरफ़ेस है, जैसे कक्षा में एक इंटरफ़ेस भी होता है। CoreFX इंटरफेस में async विधियों को पूरी तरह से ठीक कर सकता है।

.NET कोर में सतह क्षेत्र को .NET फ्रेमवर्क के साथ बाइनरी संगत होना चाहिए ताकि प्रथम पक्ष और तृतीय पक्ष .NET कोर के विरुद्ध निर्माण कर सकें, और .NET फ्रेमवर्क में बदलाव किए बिना पोर्टेबिलिटी चला सकें। इंटरफेस में सदस्यों को जोड़ने से इसका उल्लंघन होता है, क्योंकि जब वे .NET फ्रेमवर्क पर चलते हैं तो उन सदस्यों के उपभोक्ता विफल हो जाते हैं।

आसान समाधान: इंटरफेस जोड़ें जैसे वे अभी हैं। और एक बार जब आप सभी अपने होश में आ जाते हैं कि ऊपर दिया गया यह नियम वास्तव में बेवकूफी भरा है, तो आप उन तरीकों को जोड़ सकते हैं जिनकी आपको इंटरफेस में बहुत पहले जोड़ने की जरूरत थी और आगे बढ़ सकते हैं।

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

एक और बात जिसका मैं उल्लेख करना भूल गया: फाउलर ने कल ट्विटर पर उल्लेख किया कि आपको हर किसी को अपना सामान पोर्ट करने की आवश्यकता है। मुझे अपने 500K एलओसी कोडबेस को कोरएफएक्स में पोर्ट करने के लिए भुगतान करना होगा, इसमें समय, प्रयास लगता है और अन्य सुविधाओं के लिए समय लगेगा। अतिरिक्त घर्षण जो पूरी तरह से कृत्रिम है (यह एक नया मंच है! प्रतिबंधात्मक नियम कैसे हो सकते हैं?) वास्तव में बिल्कुल भी मदद नहीं करता है: यह अतिरिक्त रखरखाव लागत जोड़ता है, कोड को पोर्ट करने और परीक्षण करने के लिए अतिरिक्त समय लेता है और हमारे उपयोगकर्ताओं के लिए अतिरिक्त बोझ देता है।

ऐसा लगता है कि वह सब आपके दायरे से बाहर है, और आपकी चिंता नहीं है। लेकिन आप एक बात भूल जाते हैं: क्या _if_ हम अपना कोड और मेरे साथ और लोगों को पोर्ट नहीं करते हैं? मैं अपने बड़े कोडबेस को आपके नए चमकदार ढांचे में पोर्ट करने के लिए समय और इस प्रकार अपने पैसे का निवेश करने के लिए तैयार हूं, लेकिन यह कहने के लिए खेद है, जब भी मैं किसी समस्या में भाग लेता हूं तो मुझे प्रतिबंधों, अजीब नियमों और अंतहीन बहसों का सामना करना पड़ता है। . Iow: मुझे बहुत अकेलापन महसूस होता है जबकि साथ ही आप इतने सख्त लगते हैं कि हम आपके नए चमकदार ढांचे को पसंद करें।

जैसा कि मैंने बहुत समय पहले कहा था : मुझे यह ढांचा बेचो, यह नया CoreFX। खैर, घर्षण को बनाए रखना और बहुत सारे स्थानांतरित और दूर किए गए पनीर को पेश करना इसमें बड़ी मात्रा में समय (और पैसा) निवेश करने के लिए एक बड़ा प्रोत्साहन नहीं बना रहा है।

बस मेरे 2 सेंट।

@FransBouma कृपया इस बातचीत को पेशेवर, उत्पादक और तथ्यों पर केंद्रित रखने का प्रयास करें।

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

1) IDbConnection.OpenAsync को .NET कोर में जोड़ें
2) जो कोई भी इस पद्धति को कॉल करता है, वह अब .NET फ्रेमवर्क पर चलने में विफल हो जाएगा (एक मूल सिद्धांत/लक्ष्य को तोड़ना जिसे मैंने ऊपर कहा था)। यह एक्सएएमएल डिजाइनर और कुछ अन्य वीएस सुविधाओं को भी तोड़ता है जो इस तथ्य पर निर्भर करता है।
3) .NET Framework को अप-टू-डेट लाने के लिए, हम IDbConnection.OpenAsync के साथ .NET Framework "4.7" का एक नया संस्करण शिप करते हैं।
4) इस पद्धति को जोड़ने से पहले IDbConnection को लागू करने वाला हर एक प्रकार अब .NET Framework "4.7" पर लोड करने में विफल रहता है

यही कारण है कि हम इंटरफेस में विधियों को नहीं जोड़ सकते हैं।

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

उस ने कहा: मैंने इंटरफेस से शादी नहीं की है, इसलिए यदि वे चले गए हैं, तो तथ्य यह है कि तब से कक्षाएं हैं और सिद्धांत में काम करने के लिए कोई इंटरफेस नहीं है, मुझे उदास पांडा नहीं बनायेगा: क्या किया जाना चाहिए आधार वर्गों के माध्यम से भी सिद्धांत रूप में किया जा सकता है, आज, क्योंकि आज सभी प्रमुख ADO.NET प्रदाता अच्छा खेलते हैं और आधार वर्गों से प्राप्त होते हैं (यह पिछले IIRC में ODP.NET के साथ एक इंटरफ़ेस को लागू करने के मामले में नहीं था, लेकिन नहीं बेस क्लास से व्युत्पन्न)। यही कारण है कि मैंने शुरू में इस धागे में पहले ऊपर उठाया था, वास्तव में उन्हें हटाना एक बड़ी बात नहीं थी। तब से मेरे पास इसके बारे में सोचने के लिए कुछ समय था और मुझे लगता है कि यह एक बड़ी बात है।

हम मंगल ग्रह पर एक निर्वात में नहीं रहते हैं, और स्टैक के निचले भाग में मिडलवेयर/ढांचे में अब समस्या है: इन ढांचे के वर्तमान .NET पूर्ण संस्करणों के उपयोगकर्ता कोरएफएक्स पर उनका उपयोग करना जारी रखना चाहते हैं क्योंकि वे इन ढांचे को जानते हैं । हालांकि, उन्हें CoreFX पर पोर्ट करना एक बड़ा PITA है, क्योंकि असंख्य कारणों से, उनमें से एक को अक्सर सार्वजनिक API में उपयोग किए जाने वाले इंटरफेस का उपयोग किया जाता है जो CoreFX (और इस थ्रेड का कारण) पर मौजूद नहीं होते हैं।

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

अपने 4 कदम परिदृश्य को देखते हुए: इंटरफेस में विधियों को जोड़ना कोई समस्या नहीं है यदि आप कोरएफएक्स को एक अलग ढांचे के रूप में देखते हैं। और वैसे भी ऐसा नहीं है? यह उन सभी वर्षों पहले कॉम्पैक्ट फ्रेमवर्क के समान है (जिसे मैंने अपने ढांचे को पोर्ट किया था, और मैंने कुछ कठिन सबक सीखे, फिर मुझे बताया कि CoreFX को पोर्ट करना सरल, तेज और आसान नहीं होगा और दो कोड बेस रखना होगा। या तो नहीं होगा): हम 1 एपीआई से शुरू करते हैं, फिर कोई कुछ भूल जाता है या एमएस के भीतर किसी टीम को कुछ चाहिए, और वायोला एक ब्रेकिंग चेंज केवल एक मुट्ठी भर निम्न-स्तरीय स्टैक देव चलेंगे और इसी तरह और दो सड़कें विभाजित हो जाएंगी।

(उदाहरण: कॉम्पैक्ट फ्रेमवर्क 'SerializableAttribute' भूल गया। उन्होंने कहा कि एक डमी विशेषता के साथ बाद के संस्करण में कुछ भी नहीं कर रहा है, लेकिन उस कोड को तोड़ दिया जो उस पर मौजूद नहीं होने का अनुमान लगाता है और जो स्वयं को परिभाषित करता है)

हालांकि सड़कों को विभाजित करना समझ में आता है: चीजों को संगत रखने की कोशिश करना बहुत ही सीमित है। मैं अब यहां भविष्यवाणी करता हूं कि भविष्य में यह नियम तोड़ा जाएगा।

चीजों को 'संगत' के रूप में देखना न केवल एपीआई हस्ताक्षर स्तर पर, बल्कि एपीआई _behavior_ स्तर पर भी महत्वपूर्ण है। यह विश्वास करना कि एपीआई व्यवहार में वे दोनों पूरी तरह से समान होंगे (CoreFX और .NET Full) बहुत जोखिम भरा है: एक फ्रेमवर्क डेवलपर को CoreFX और .NET पूर्ण पर समान कार्यक्षमता का परीक्षण करना होगा, अकेले CoreFX पर परीक्षण करने का कोई तरीका नहीं होगा। यह मानने के लिए पर्याप्त है कि कोड भविष्य में पूर्ण .NET पर 100% समान काम करता है: क्योंकि आप इसकी गारंटी कैसे दे सकते हैं? CoreFX पर कॉल स्टैक 20 कॉल डीप ने .NET पूर्ण की तुलना में बहुत अधिक अन्य कोड को छुआ है, यहां और वहां एक छोटा विवरण और चीजें बदल जाती हैं।

इस सब में बिंदु यह है: यह एक अलग ढांचा है: कोरएफएक्स के खिलाफ संकलित कोड .NET पूर्ण के खिलाफ संकलित कोड से अलग होने की उम्मीद की जा सकती है।

कुछ स्थितियां हैं:

1) एक ढांचे का एक कोड आधार होता है जिसमें से 100% CoreFX पर संकलित होता है। यह एक dll देता है जो पूर्ण .NET पर चलने योग्य है
2) एक फ्रेमवर्क का एक कोड आधार होता है, जिसमें से 70% CoreFX पर और 100% .NET पर संकलित होता है। यह 2 dll देता है: एक CoreFX के लिए, और एक .NET पूर्ण के लिए। CoreFX संस्करण को .NET पूर्ण पर चलाना मूर्खतापूर्ण है, क्योंकि कोई 30% कार्यक्षमता से चूक जाता है।

1 के मामले में) मैं आपकी बात समझता हूँ। 2 के मामले में (जो सभी मौजूदा .NET पूर्ण लक्ष्यीकरण ढांचे के मामले में है, उनमें से _all_ तृतीय पक्ष ओआरएम) आपका बिंदु वास्तव में व्यर्थ है, क्योंकि उन्हें वैसे भी 2 डीएलएस के साथ काम करना होगा: प्रभावी रूप से 2 कोडबेस जिन्हें करना है अलग से बनाए रखा जाएगा, अलग से परीक्षण किया जाएगा और अपने स्वयं के नए संस्करणों में अलग से माइग्रेट किया जाएगा। विशेष रूप से यदि CoreFX को नई सुविधाएँ मिलती हैं जो अभी तक .NET पूर्ण (जो मामला होगा) का हिस्सा नहीं हैं। (बीटीडब्ल्यू: यदि आप कोरएफएक्स में DbDataReader.GetSchemaTable() जोड़ते हैं जो डेटाटेबल की तुलना में एक अलग डेटास्ट्रक्चर देता है, क्योंकि एमएस ने इसे पोर्ट करने से इंकार कर दिया है, कोरएफएक्स पर डीबीडेटा रीडर का उपयोग कर कोड। नेट पर भी टूट जाएगा। यदि आप इसे अलग तरह से नाम देते हैं यह टूट जाएगा और साथ ही विधि नहीं है। Iow: कोड टूट जाएगा यदि चीजें जो _both_ ढांचे में नहीं हैं उपयोग किया जाता है। इसका मतलब यह नहीं है कि चीजें इस प्रकार CoreFX में मौजूद नहीं होनी चाहिए)।

CoreFX पर कोई इंटरफेस नहीं होने से स्थिति 2 में ढांचे की स्थिति बन जाती है) एक लगातार: वे एक ढांचा बनने के लिए आगे नहीं बढ़ सकते हैं जो 1 में फिट बैठता है) क्योंकि उदाहरण के लिए उनका एपीआई इंटरफेस को उजागर करता है।

माइक्रोसॉफ्ट अपने स्वयं के सामान को फिर से लिख रहा है ताकि उनके ढांचे 1 स्थिति में ढांचे बन जाएं) अच्छा है, हालांकि हमारे पास एक मिलियन डॉलर का बजट नहीं है, ओआरएम रनटाइम पर 15+ लोग और हमारी तरफ एक बड़ी पीआर मशीन है जो झुर्रियों को सुचारू करेगी वहाँ से बाहर हर ऐप को तोड़ना। तो हम या तो 2 में फंस गए हैं) या एमएस से 1 पर जाने के लिए थोड़ी मदद की आवश्यकता है)।

यहां यही दांव पर लगा है। आपने ट्विटर पर कहा "हमें बताएं कि आपको क्या चाहिए"। हमने किया। बार-बार। विशेष रूप से System.Data के संबंध में कोई संचार

अगर इससे मुझे निराशा होती है और भगवान 'गैर-पेशेवर' न करे, तो ऐसा ही हो।

सुनने के लिए धन्यवाद। बीटीडब्ल्यू मुझे सिस्टम पर कोई भ्रम नहीं है। डेटा: यह पोर्ट कोड के लिए एक एपीआई का ट्रेनव्रेक होगा और चूंकि डेवलपर्स के साथ प्रभारी लोगों से कोई संचार नहीं होता है जो अपने एपीआई के शीर्ष पर महत्वपूर्ण ढांचे लिखते हैं, वहां कोई उम्मीद नहीं है चीजें बदल जाएगा। आपकी गलती नहीं है, @davkean , यह कुछ भी व्यक्तिगत नहीं है।

मुझे संचार की कमी के बारे में उपरोक्त निराशाओं को प्रतिध्वनित करना होगा। हमें बल्क इंसर्ट और स्कीमा जानकारी भी चाहिए। इन लापता कोर (दोनों तरीकों से) कार्यक्षमता में एक महीने से अधिक समय में कोई प्रगति या संचार नहीं हुआ है (देखें डॉटनेट/रनटाइम#15269 और डॉटनेट/रनटाइम#14302)। फिर भी, Microsoft वर्तमान कोड को "रिलीज़ के लिए एक उम्मीदवार" के रूप में लेबल कर रहा है, जो स्वयं "यह काफी अच्छा है" का संदेश है। यह। मूल चीजें गायब हैं जिन्हें जोड़ने की आवश्यकता है और यदि आप इन थ्रेड्स का पालन करते हैं, तो समान संस्करण कारणों के लिए पहले संस्करण में होने की आवश्यकता है ।

डॉटनेट/रनटाइम#14302 ("डेटाटेबल/व्यू/सेट अनुपस्थित क्यों है?") पर अंतिम अपडेट देखें, यह 22 दिन पहले से पूछ रहा है:

तो System.Data.Common अब CoreCLR के V1 के लिए पूर्ण सुविधा है?

हां, निराशा गैर-पेशेवर के रूप में सामने आ सकती है। पाठ का स्वर और संदर्भ बेकार है और हमेशा होता है, लेकिन हम यहां तक ​​ही सीमित हैं। मुझे लगता है कि हर कोई यहां उत्पादक बनने की कोशिश कर रहा है, लेकिन हमें कोरएफएक्स की ओर से System.Data क्षेत्र में वास्तविक प्रगति पर काफी कुछ पत्थरबाजी हो रही है और वह है, कुंद होना, एक पुस्तकालय लेखक के रूप में दोनों को क्रुद्ध करना और इन बिट्स का एक उपयोगकर्ता।

हमें इन मुख्य कार्यात्मक टुकड़ों, इंटरफेस की आवश्यकता है या नहीं - मैं इंटरफेस पर कठोर नहीं हूं और हमने उनके बिना डैपर को पोर्ट किया है। लेकिन डेटाटेबल की कमी, परिणाम स्कीमा जानकारी, थोक सम्मिलन, और ऐसे "रिलीज उम्मीदवार" में अस्वीकार्य हैं। Microsoft वह है जो वर्तमान कोड को RC के रूप में लेबल करने के साथ निराशा बढ़ा रहा है जब यह लगभग सार्वभौमिक रूप से सहमत है कि यह रिलीज़ के लिए तैयार नहीं है। हां, यह सिर्फ एक लेबल है, लेकिन यह एक गलत लेबल है और एक ऐसा है जो तात्कालिकता के स्तर को काफी बढ़ा देता है क्योंकि यह एक मनमाना शेड्यूल पर आधारित है (जिसे वास्तविकता को प्रतिबिंबित करने के लिए बदलना चाहिए था)। मुझे नहीं लगता कि इस सूत्र में कोई भी उस कार्यक्रम के लिए जिम्मेदार है, लेकिन यह निराशा _level_ में एक प्रमुख कारक के रूप में बताए जाने योग्य है।

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

आइए 1M+ डाउनलोड के साथ NHibernate को न भूलें:

| आईडीबी कनेक्शन | आईडीबी कमांड | आईडीटा रीडर |
| --- | --- | --- |
| 59 | १८१ | 132 |

वर्तमान धारणा यह है कि ADO.NET/CoreCLR को EF और SQL सर्वर के लिए प्रथम श्रेणी का समर्थन प्रदान करने के लिए फिर से डिज़ाइन किया जा रहा है, बाकी पारिस्थितिकी तंत्र की अवहेलना की जा रही है - इस तरह के गैर-पारदर्शी ब्रेकिंग निर्णय केवल इस स्टीरियोटाइप को फिर से लागू करने के लिए जाते हैं .

यह धारणा इस तरह की चीजों से पुष्ट होती है: https://github.com/dotnet/corefx/issues/4646

जहां तक ​​​​मैं कह सकता हूं, एसक्ल क्लाइंट असेंबली के बाहर किसी भी उपयोगी तरीके से उस एपीआई को लागू करने का

मैं वर्तमान में इंटरफेस के बिना परीक्षण के साथ ठीक हूं। लेकिन ईमानदारी से मुझे इंटरफ़ेस संस्करण और संगतता के साथ तर्क नहीं मिलता है।

क्या .NET कोर का विचार यह नहीं है कि यह संगतता के बोझ के बिना एक नया ढांचा है, और यह आपके एप्लिकेशन के साथ बंडल है, इसलिए आपको इस तरह के मुद्दों से निपटने की ज़रूरत नहीं है? स्कीमा और डेटाटेबल्स जैसी चीज़ों की कमी के कारण प्रदाता .NET में पहले से ही असंगत है, तो किसके साथ संगतता टूट जाएगी? यदि इंटरफ़ेस बदलता है, तो बस नए संस्करण के विरुद्ध संकलित करें और इसे अपने ऐप के साथ बंडल करें।

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

उन लोगों के लिए जो कई ढांचे का समर्थन करने का इरादा रखते हैं, और ऐतिहासिक रूप से इंटरफेस को लक्षित करते हैं ... मैं सिर्फ डैपर द्वारा उपयोग किए जाने वाले बदसूरत ढेर को साझा करना चाहता हूं; मैं यह नहीं कह रहा हूं कि यह _good_ है, लेकिन इसे संकलित करने के लिए पर्याप्त है। बेशक, यह फाइलों के एक विशाल ढेर में दोहराया गया है ... मैं इसे मुख्य रूप से एक और प्रभाव पर जोर देने के लिए साझा कर रहा हूं:

https://github.com/StackExchange/dapper-dot-net/blob/master/Dapper/SqlMapper.cs#L6 -L16

हम सदस्यों को इंटरफेस में नहीं जोड़ सकते

सही है, और यह इंटरफेस की एक _good_ विशेषता है। एब्सट्रैक्ट बेस क्लास की प्राथमिकता एपीआई एन्ट्रापी को लड़ने के बजाय मदद करने का सबसे सुरक्षित तरीका है।

जबकि आपके पास OOD के इंटरफ़ेस पृथक्करण सिद्धांत (ISP) कहता है कि _no क्लाइंट को उन तरीकों पर निर्भर रहने के लिए बाध्य नहीं किया जाना चाहिए जिनका वह उपयोग नहीं करता_।

यदि आप किसी मौजूदा अमूर्तन में नई विधियाँ जोड़ते हैं, तो आप स्वतः ही ISP का उल्लंघन करते हैं।

आप तय कर सकते हैं कि आपको 'सॉलिड का पालन करने की आवश्यकता नहीं है' क्योंकि आप माइक्रोसॉफ्ट हैं, और आप बीसीएल के साथ काम कर रहे हैं, इसलिए 'सामान्य नियम लागू नहीं होते' (वास्तविक उद्धरण नहीं; केवल सामान्य को स्पष्ट करना जवाबी तर्क)।

6-7 वर्षों के लिए कुछ ओपन सोर्स प्रोजेक्ट बनाए रखने के बाद, मेरे अनुभव में इंटरफेस को छोटा रखना बेहतर है। यदि आपको अमूर्त में नई क्षमताएँ जोड़ने की आवश्यकता है, तो एक नया इंटरफ़ेस पेश करें।

• " एक इंटरफ़ेस के लिए कार्यक्रम, कार्यान्वयन नहीं। "
• " वर्ग विरासत पर वस्तु संरचना का पक्ष लें। "

अगर यहाँ अपवोट होते , तो मैं अपवोट करता

हमेशा की तरह @ploeh से व्यावहारिक टिप्पणी।

@FransBouma , हम DbDataReader.GetSchemaTable() की प्रतिस्थापन कार्यक्षमता को इस तरह से जोड़ेंगे कि यह पूर्ण ढांचे को नहीं तोड़ेगा।
@NickCraver , SqlBulkCopy हमारी भविष्य की योजना में है और हम स्कीमा पर काम कर रहे हैं। हम स्कीमा पर प्रगति करने में धीमे हैं क्योंकि हमें अपने स्टैक को एक्स-प्लेटफ़ॉर्म पर काम करने के लिए उचित प्रगति करने की भी आवश्यकता है।
@mythz , ग्राहक प्रभाव पर उदाहरण, संख्या और मूल्यांकन प्रदान करने के लिए धन्यवाद। हम उनकी समीक्षा करेंगे।

@YoungGah कृपया जानकारी से जुड़े मुद्दों को अपडेट करें ताकि ये मुद्दे अद्यतित रहें, जैसे https://github.com/dotnet/corefx/issues/1039 , अन्यथा विरल जानकारी चारों ओर बिखरी हुई है। यह अच्छा है कि आप GetSchemaTable (और DbConnection के समकक्ष, उसे न भूलें!) जोड़ रहे हैं, लेकिन क्या होगा और _जब_ के बारे में कोई जानकारी प्राप्त करना बहुत कठिन है। क्या कोई योजना है कि कब क्या जोड़ा जाएगा? अभी हमें केवल एक संकेत देना है कि 'भविष्य' में कुछ जोड़ा जा सकता है। ईमानदार होने के लिए, कोड बेस के बंदरगाह की योजना बनाने के लिए यह वास्तव में बहुत अच्छा नहीं है।

@FransBouma , हाँ, मैं अन्य धागे भी अपडेट करूंगा। क्या और कब उपलब्ध होगा, इस बारे में अधिक जानकारी के लिए आपके अनुरोध के लिए, मैं पूरी तरह से समझता हूं कि आप लोगों को इसकी आवश्यकता क्यों है। मैं उस सूची को प्रकाशित करूंगा जो इंगित करेगी कि क्या सुविधा/कार्यक्षमता v1 पर उपलब्ध होगी, उद्देश्य से हटाई गई, v1 के बाद उपलब्ध होगी, या भविष्य की उपलब्धता का डिज़ाइन लंबित है। मैं इसे अगले 2 सप्ताह के दौरान पोस्ट करने का प्रयास करूंगा। जहां तक ​​DbDataReader और DbConnection फ़ंक्शन पर स्कीमा फ़ंक्शन प्राप्त करने का संबंध है, हमारी योजना इसे rc2 रिलीज़ के लिए उपलब्ध कराने की है। अगर कुछ अप्रत्याशित कारणों से योजना बदलती है, तो हम समुदाय को अपडेट करेंगे।

यहां कभी क्या होता है, और भविष्य के संदर्भ के लिए @YoungGah; IDataReader की डेटाटेबल पर निर्भरता है, जिसकी डेटासेट पर निर्भरता है (जिसे हम एक अलग परत मानते हैं - क्योंकि यह नीति भारी है, इन प्रकारों के विपरीत जो नीति-मुक्त हैं), इसलिए यहां कुछ डिज़ाइन कार्य हैं जो इसे तोड़ने के लिए हैं यदि ये इंटरफेस कभी थे वापस लाया।

मैं @ploeh के दृष्टिकोण के लिए यहां एक और वोट @davkean की

आपके पास पुराने को इनहेरिट करने वाला नया इंटरफ़ेस क्यों नहीं हो सकता। पुराने को खत्म करो। भविष्य में पुराने को हटा दें। कम से कम तब आप इसे बढ़ा सकते हैं और मौजूदा उपयोगों को नहीं तोड़ सकते।

या कई छोटे इंटरफेस। मुझे अभी टिप्पणी करनी है।

मैं यह नहीं समझता कि मूल .NET के साथ पूर्ण संगतता की आवश्यकता है। यहां तोड़ने के लिए कुछ भी नहीं है, यह एक नया ढांचा है और विरासत कोड के साथ संबंधों को तोड़ने और उन परिवर्तनों को लागू करने का सही अवसर है जो लंबे समय से आवश्यक हैं लेकिन मूल ढांचे में चोट पहुंचाएंगे।

जब मैंने इंटरफेस को वापस प्रस्तावित किया, तो मैं मूल 1.1 इंटरफेस लाने के बारे में नहीं सोच रहा था, लेकिन नए डिजाइन के साथ अद्यतन इंटरफेस। उनमें से और भी हो सकते हैं, जैसा कि @ploeh ने कहा था।

इंटरफेस हां, यदि संभव हो तो विरासत समर्थन, लेकिन इस बिंदु पर प्राथमिकता नहीं होनी चाहिए।

फिर से खोलना क्योंकि इस विषय में बहुत रुचि है।

यहां तोड़ने के लिए कुछ भी नहीं है, यह एक नया ढांचा है और विरासत कोड के साथ संबंधों को तोड़ने और उन परिवर्तनों को लागू करने का सही अवसर है जो लंबे समय से आवश्यक हैं लेकिन मूल ढांचे में चोट पहुंचाएंगे।

तो मूल खराब तरीके से डिज़ाइन किए गए इंटरफेस से छुटकारा पाने और ADO.NET जैसे बेस क्लास पर मानकीकरण करने का सही मौका पहले से ही कर रहा है? :ट्रॉल फ़ेस:

गंभीरता से हालांकि, आपके पास एक स्वच्छ एपीआई या पश्चगामी संगतता के बीच एक विकल्प है। एक चुनें। मुझे आपका केक रखने और उसे खाने का कोई तरीका नहीं दिख रहा है।

@JamesNK लेकिन वह बिल्कुल सही बात होगी। पश्च संगतता आवश्यक नहीं है, अवधि।

आप मजाक करते हैं, लेकिन इंटरफेस के साथ खराब डिजाइन एपीआई खराब थे क्योंकि वे बुरी तरह डिजाइन किए गए थे, इसलिए नहीं कि वे इंटरफेस थे। =) ऐसा नहीं है कि NET में हर जगह इंटरफेस का उपयोग बिल्कुल नहीं किया जाता है या यह कुछ नया है। बस इस बार चीज़ को सही ढंग से डिज़ाइन करें और आगे बढ़ें।

ADO.NET सभी .NET में कोड के सबसे स्थिर टुकड़ों में से एक है। 15 साल में इसमें दो या तीन गंभीर बदलाव हुए। यह एक इंटरफ़ेस को स्थिर करने और सभी के लिए इसे आसान बनाने के लिए एकदम सही एपीआई है।

एक नोट के रूप में, यह विषय यहां सबसे अधिक टिप्पणी किए गए मुद्दों में से एक है, और इंटरफेस बनाम वर्चुअल विधियों, टेस्टेबिलिटी और सामान पर एक ही लंबी चर्चा थी।

@nvivo मुझे स्वीकार करना होगा, मैं उलझन में हूँ। जब हमने यह स्थापित किया कि बेस क्लास ने टेस्टेबिलिटी को सक्षम किया, तो यह थ्रेड .NET फ्रेमवर्क कोड को .NET कोर में पोर्ट करने में सक्षम बनाने के लिए इंटरफेस को वापस लाने में बदल गया। इंटरफेस को फिर से डिजाइन करने और कुछ नया पेश करने से कैसे मदद मिलती है?

पिछड़े संगतता के लिए हमारे पास मूल इंटरफेस क्यों नहीं हो सकते हैं और जो कुछ भी आप चुनते हैं (या तो अमूर्त वर्ग या छोटे इंटरफेस) के साथ आगे बढ़ सकते हैं? मूल इंटरफेस नए स्टैक के शीर्ष पर बैठ सकते हैं और पिछड़े संगतता प्रदान कर सकते हैं। यह हिस्सा वैकल्पिक भी हो सकता है।
यह पोर्टिंग को आसान बना देगा और फिर भी नए तरीके की अनुमति देगा।

@davkean

मैं यहां टिप्पणी करने वाले सभी लोगों के लिए प्रतिक्रिया नहीं दे सकता। मैंने ADO.NET के एपीआई के रूप में इंटरफेस का उपयोग करने का प्रस्ताव रखा, जिसे नए वर्तमान एपीआई में अपडेट किया गया। मैंने मूल इंटरफेस और इसकी सभी समस्याओं को लाने के लिए नहीं कहा था। इसका उद्देश्य एक क्लीनर परिभाषित एपीआई होना था और इसे मॉक करना और उस पर निर्भर कोड का परीक्षण करना आसान बनाना था, ज्यादातर डेटा एब्स्ट्रैक्शन लाइब्रेरी और उपयोगकर्ता कोड नहीं।

एपीआई का वर्णन करने के लिए इंटरफेस बेहतर हैं जैसा कि @ploeh ने बुद्धिमानी से कहा है, और एक नरक का

अब, बस यह देखने के लिए कि कैसे कक्षाएं पहले से ही खराब डिज़ाइन बना रही हैं:

• DbCommand के पास DesignTimeVisible संपत्ति क्यों है? क्या कनेक्शन के रूप में परिभाषित किए जाने वाले कनेक्शन के लिए डिज़ाइन समय समर्थन एक आवश्यकता है?
• राज्य परिवर्तनों को
• क्या एक कनेक्शनस्ट्रिंगबिल्डर एक प्रदाता के अस्तित्व के लिए एक आवश्यकता है? या वीएस विज़ार्ड बॉक्स से बाहर काम करने के लिए एक अच्छी बात है?
• क्यों DbDataReader कुछ मुख्य प्रकारों के लिए Get विधियों को परिभाषित करता है लेकिन GetByteArray() और GetDateTimeOffset() जैसे अन्य के लिए नहीं जोड़ता है? और एक टेक्स्ट रीडर को GetSql* परिवार)?

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

ईमानदारी से, डिजाइन की चर्चा के बाहर से ऐसा लगता है जैसे यह चला गया:

• आइए इन घटनाओं को यहां रखें क्योंकि विजुअल स्टूडियो में जादूगरों के लिए बॉक्स से बाहर काम करना आसान है
• आइए स्कीमा पुनर्प्राप्ति विधियों को हटा दें क्योंकि हमारे पास ईएफ है और यही वह है जो दुनिया में हर किसी को उपयोग करना चाहिए, अवधि।
• आइए इन सुविधा विधियों को रखें क्योंकि यह .NET 1.1 के बाद से समर्थित है और हम संगतता को कभी भी तोड़ नहीं सकते हैं!
• आइए डेटाटेबल्स और डेटासेट को हटा दें और .NET 1.1 से आने वाले सभी लोगों को अपना पूरा कोडबेस वैसे भी बदल दें!
• आइए क्लाउड कंप्यूटिंग, समुदाय, ओपन सोर्स और कल के अनुप्रयोगों पर केंद्रित एक नया प्रदाता मॉडल बनाएं...
• ... और इस मॉडल को _sole_ टेस्ट केस के रूप में SqlClient का उपयोग करके कल की जरूरतों के आधार पर बनाते हैं!
• आइए एक नया ढांचा तैयार करें जो प्रत्येक एप्लिकेशन के साथ बंडल किया जाएगा, इसलिए किसी को भी अपने एप्लिकेशन को तोड़ने वाले अपडेट के बारे में चिंता करने की ज़रूरत नहीं है _everफिर से_!
• .. तो चलिए फिर इंटरफेस न जोड़ने का निर्णय लेते हैं क्योंकि कोई भी परिवर्तन उनके अपडेट को तोड़ सकता है!

हाँ, वहाँ एक छोटी सी शेख़ी है और यह चर्चा कहीं नहीं जा रही है =)... लेकिन बस इसे अपने सीने से बाहर निकालना चाहता था। यह 2015 है, हर समय सब कुछ टूट जाता है और हम इसके अभ्यस्त हो जाते हैं। अगले वर्षों में ASP.NET MVC में 20 अपडेट होंगे जो ADO.NET में इंटरफ़ेस परिवर्तनों की तुलना में बहुत अधिक ब्रेकिंग परिवर्तन का कारण बनेंगे।

मुझे अब भी .NET पसंद है और आप इसके साथ सामान्य रूप से क्या कर रहे हैं, मुझे यकीन है कि .NET Core v1 को समय पर प्राप्त करना जल्दबाजी होगी और सब कुछ सही नहीं होगा। मुझे उम्मीद है कि समय बीतने के साथ समुदाय इसे अन्य दिशाओं में ले जाने में मदद कर सकता है और जैसे ही हम आगे बढ़ते हैं आप चीजों को तोड़ने से डरते नहीं हैं।

ORM अनुरक्षकों के लिए, क्यों न करें

``` सी#

अगर कोरएफएक्स

नेमस्पेस सिस्टम। डेटा {
सार्वजनिक इंटरफ़ेस आईडीबीकनेक्शन {...}
}
```

और अपने स्वयं के कार्यान्वयन के साथ नए System.Data को लपेटने के लिए एडेप्टर पैटर्न का उपयोग करें? वास्तव में आप इसके लिए एक ओपन सोर्स कोड पैकेज बना सकते हैं और साझा कर सकते हैं।

It's 2015, everything breaks all the time and we're used to it. There will be 20 updates to ASP.NET MVC in the next years that will cause a lot more breaking changes than interface changes in ADO.NET.

I still love .NET and what you're doing with it in general, I'm sure it's a rush to get .NET Core v1 out in time and not everything will be perfect. I just hope the community can help steer this to other directions as the time goes and you're not afraid to break things as we move.
- nvivo

यही समस्या है; एक सुविचारित दृष्टिकोण के बजाय हम कुछ मनमानी समय सीमा को पूरा करने के लिए एक त्वरित पुनर्लेखन प्राप्त कर रहे हैं।
मैं जल्द ही देर हो चुकी थी, Q4/16 यदि आवश्यक हो, तो कुछ चमकदार नए टूटे हुए बकवास की तुलना में। यह 2015 है और सब कुछ टूट जाता है एक भयानक औचित्य है।

@thefringeninja जो या तो पूरी तरह से अनावश्यक और भ्रमित करने वाली निर्भरता जोड़ता है जो केवल आधे सिस्टम (साझा मामले में) के साथ काम करता है, या नाम टकराव की ओर जाता है जिसके लिए extern alias को अनपिक करने की आवश्यकता होती है (और बहुत भ्रम की स्थिति क्यों होती है a System.Data.IDbConnection अलग-अलग-लेकिन-समान System.Data.IDbConnection स्वीकार नहीं करेगा जो आप इसे पेश कर रहे हैं)। मूल रूप से, यह चीजों को 10 गुना बदतर बना देगा।

क्या आप एक ठोस उदाहरण @mgravell दे सकते हैं? मैं देख सकता हूं कि यदि आप Type.GetType("System.Data.IDbConnection, System.Data") , या शायद पीसीएल परिदृश्यों में उपयोग करते हैं तो यह कैसे टूट जाएगा।

यदि orm A System.Data.IDbConnection को परिभाषित करता है, और orm B परिभाषित करता है
System.Data.IDbConnection, तो अब दो पूरी तरह से अलग हैं और
असंगत इंटरफेस जिनमें समान नाम/नामस्थान, विरोध, और
वास्तव में किसी भी डीबी प्रदाता से काम नहीं करते हैं। यह कुछ भी हल नहीं करता है,
मूल रूप से। इससे भी बदतर: यह अनुपयोगी एपीआई को पट्टे पर देता है जहां कोई पास होने की उम्मीद करता है
एक SqlConnection या NgpSqlConnection में - और यह काम नहीं करता है।

वास्तव में आप इसके लिए एक ओपन सोर्स कोड पैकेज बना सकते हैं और साझा कर सकते हैं।

यदि यह System.Data.Common नहीं है, तो इसका मतलब है कि DbConnection इसे लागू नहीं करता है, और : आप शायद परेशान न हों।

आपको हर ओआरएम या एडीओ .NET प्रदाता अनुरक्षक के लिए बाहरी तृतीय पक्ष निर्भरता (काफी गारंटी SQL सर्वर अभ्यस्त) पर लेने के लिए आम सहमति नहीं मिलेगी और एक कोर बीसीएल इंटरफ़ेस को फिर से परिभाषित करने वाले 2 पुस्तकालयों का एक साथ उपयोग नहीं किया जा सकता है। हाई-लेवल फ्रेमवर्क (जैसे सर्विसस्टैक) के लिए और भी बदतर जो सिस्टम को संदर्भित करता है। कोर लिबास में डेटा इंटरफेस (जिसे अब इसे परिभाषित करने की आवश्यकता होगी) अब किसी भी ओआरएम का उपयोग करने में सक्षम नहीं होगा जो समान इंटरफेस का संदर्भ नहीं देता है - जो नहीं -एक होगा या करना चाहिए।

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

@mgravell आह सकर्मक निर्भरता, उस पर विचार नहीं किया था। :+1:

आप जानते हैं कि मैं यह नहीं देखता कि यह एक मुद्दा क्यों है जब तक कि आप अपने कोड को उस कोड से कसकर जोड़ नहीं रहे हैं जो आपके पास नहीं है। अपने कोड को इसकी निर्भरता से सुरक्षित रखें! इसे लपेटो और इसे दूर करो। ऐसा करने और अपने कोड को परीक्षण योग्य बनाने के कई तरीके हैं। कई का उल्लेख ऊपर किया गया है। आप एकीकरण उन बिट्स का परीक्षण करते हैं जो आपके पास नहीं हैं। यही काम करता है। आपको बीसीएल वस्तुओं का मज़ाक नहीं उड़ाना चाहिए! अगर आप हैं तो आपका डिजाइन अच्छा नहीं है।

@nvivo मुझे लगता है कि यह आपका मूल मुद्दा है, लेकिन इसकी दिशा अब संगत कारणों से v1 युग के इंटरफेस को वापस लाने के बारे में एक सूत्र में बदल गई है। आइए इसे उस पर केंद्रित रखें - यदि आप वर्तमान सतह क्षेत्र में परिवर्तन करने पर चर्चा करना चाहते हैं, तो कृपया नए मुद्दे दर्ज करें।

@mythz दो मुद्दे हैं जो हमारे पास इंटरफेस के साथ थे; 1) वे डेटासेट पर एक (भारी) निर्भरता लाए, जो नीति-मुक्त सार से संबंधित नहीं है और 2) वे आधार वर्गों के लिए अमूर्त के समानांतर सेट में लाते हैं लेकिन v1 सतह क्षेत्र के साथ बंद हैं। हम उस भ्रम से बचना चाहते थे।

मैं मानता हूं कि किसी तृतीय पक्ष के लिए इन इंटरफेस को प्रदान करना व्यवहार्य नहीं है - उपयोगी होने के लिए उन्हें मूल सार तत्वों पर लागू करने की आवश्यकता है।

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

इसका बिल्कुल कोई मतलब नहीं है।

@nvivo इसका मतलब है, आप इसे दायर करने के बावजूद इस मुद्दे के साथ नहीं हैं - इसे बंद करने से स्पष्ट है। मुद्दा System.Data इंटरफेस को बहाल करने के बारे में है ताकि पूरे पारिस्थितिकी तंत्र का समर्थन करने के बोझ को कम किया जा सके जो उन पर निर्भर है। ऐसा लगता है कि आप इसके साथ ठीक हैं:

यह 2015 है, हर समय सब कुछ टूट जाता है और हम इसके अभ्यस्त हो जाते हैं।

लेकिन यह हममें से उन लोगों के लिए संतोषजनक रणनीति नहीं है जो मौजूदा कोड आधारों और हमारे ग्राहक के कोड-आधारों का समर्थन करते हैं, और निश्चित रूप से सभी .NET को प्रभावित करने वाले बीसीएल पुस्तकालयों के संरक्षकों के लिए डिफ़ॉल्ट रणनीति नहीं होनी चाहिए।

लेकिन यह हममें से उन लोगों के लिए संतोषजनक रणनीति नहीं है जो मौजूदा कोड आधारों का समर्थन करते हैं

@mythz यह संदर्भ से बाहर है। मेरा ये मतलब नहीं था। यहां सभी को मौजूदा कोड बेस का समर्थन करना है, मुझे संदेह है कि चर्चा में .NET के लिए कोई नवागंतुक है।

इस बातचीत में जो मुद्दा बदल गया, वह यह है कि इसका कोई खास मतलब नहीं है। .NET Core एक नया ढांचा है, अपग्रेड नहीं। बहुत सारे मौजूदा पूर्ण .NET API मौजूद नहीं हैं और न होंगे। पिछड़ी संगतता वैसे भी काम नहीं करेगी।

@nvivo यह सटीक भावना यही कारण है कि यह समस्या आप पर लागू नहीं होती है। यदि आपको लगता है कि पश्चगामी संगतता महत्वपूर्ण नहीं है, तो आपने कभी भी एक से अधिक प्लेटफॉर्म को लक्षित करने वाले सार्थक कोड-बेस का समर्थन करने का प्रयास नहीं किया है - आप CoreCLR टीम की ओर से भी नहीं बोल रहे हैं। इन पुस्तकालयों को खरोंच से विकसित नहीं किया गया था, यदि आप ऊपर पढ़ते हैं तो आप पाएंगे कि कोरसीएलआर पुस्तकालयों के लिए पूर्ण .NET फ्रेमवर्क पर चलना प्राथमिक लक्ष्य है। CoreCLR एक अन्य प्लेटफ़ॉर्म लक्ष्य है जिसमें मौजूदा पुस्तकालयों को पोर्ट करना इसकी सफलता के लिए महत्वपूर्ण है, कुछ ऐसा जो .NET टीम सक्रिय रूप से प्रोत्साहित कर रही है और जो ये लापता इंटरफेस वर्तमान में बाधा बन रहे हैं।

इंटरफेस के संस्करण के अनुकूल नहीं होने के बारे में इस सब बातों के साथ यह मुझे इस बारे में सोचने पर मजबूर करता है कि गो प्रोग्रामिंग भाषा इस समस्या को निहित इंटरफेस के साथ कैसे दूर करती है।

मुझे _policy-free_ अबास्ट्रक्शन से जो मतलब है, उस पर विस्तार करने के लिए कहा गया था।

मूल रूप से, पॉलिसी-फ्री से मेरा मतलब है कि System.Data.Common एब्स्ट्रैक्शन में लगभग शून्य व्यावसायिक नियम होते हैं - वे केवल एपीआई का एक आकार प्रदान करते हैं जिसे किसी दिए गए प्रदाता को लागू करना चाहिए। यह डेटासेट के विपरीत है, जिसमें बहुत सारे व्यावसायिक नियम और कोड हैं। नीति-मुक्त प्रकार, उनके बहुत ही निर्माण के कारण, नीति वाले प्रकारों की तुलना में कम बार संस्करण होते हैं, क्योंकि इसमें कम कोड होता है, इसलिए कम बग और डिज़ाइन परिवर्तन होते हैं। हम एक बड़े पैकेज ग्राफ़ पर निर्भरता का समन्वय करते समय आपके सामने आने वाली समस्याओं की संख्या को कम करने के लिए तीसरे पक्ष के पुस्तकालयों के बीच _exchanged_[1] संस्करण में बार-बार [2] अमूर्त और प्रकार चाहते हैं। आप अपने आवेदन के हिस्से के रूप में एक्सचेंज प्रकारों को एम्बेड या इलमर्ज नहीं कर सकते हैं, जबकि गैर-विनिमय प्रकार आप कर सकते हैं। इसलिए, हम उन्हें अलग क्यों करना चाहते हैं।

[१] _exchanged_ से, मेरा मतलब उन प्रकारों से है जो सार्वजनिक एपीआई पर दिखाई देते हैं। उदाहरण के लिए, हम Collection<T> एक विनिमय प्रकार मानते हैं, लेकिन List<T> ।
[२] इनके लिए सिमेंटिक वर्जनिंग का उपयोग करना हटाए गए इंटरफेस के साथ लगभग ऊपर के समान ब्रेक का कारण होगा, क्योंकि आप पारिस्थितिकी तंत्र को "कांटा" करते हैं; पुस्तकालयों को यह निर्णय लेने की आवश्यकता है कि विराम से पहले या बाद में पुस्तकालय को लक्षित करना है, या विभाजन को संभालने के लिए खुद को फोर्क करना है।

@mythz मुझे एक वाणिज्यिक ऐप और मौजूदा कोड के हिस्से के रूप में

अगर इसमें कुछ इंटरफेस नहीं हैं तो इसके साथ सौदा करें ... एक कंपाइलर निर्देश के साथ।

ओह? कैसे एक विधि के बारे में जो IDataReader लौटाता है, या एक विधि जो IDbConnection स्वीकार करती है? या आईडीबी ट्रांज़ेक्शन? आप उसके आसपास #ifdev कैसे जा रहे हैं, यदि आपका _customers_ कोड उस एपीआई का उपयोग करता है?

'इससे ​​निपटो'... यह कैसा अहंकार है?

सरल, अपने स्वयं के प्रकार या आधार प्रकार को वापस करने के लिए अंतर्निहित पैकेज (आपका संगठन) को अपडेट करें जिसे उन्होंने 2.0 के बाद से समर्थित किया है। यदि आप .net के पुराने संस्करणों को लक्षित कर रहे हैं तो आप इसके बजाय इंटरफ़ेस को वापस करने के लिए निर्देश का उपयोग कर सकते हैं और इसे बहिष्कृत के रूप में चिह्नित कर सकते हैं।

हाँ यह बेकार है, लेकिन मुझे यकीन है कि उन्होंने (वास्तव में स्मार्ट व्यक्ति जो हर समय इस बारे में सोचते हैं) ने उस समय एक अच्छे कारण के लिए किया था (वापस .net 2.0 में)। क्या कोई बात हो सकती है और हो सकता है कि यह निश्चित रूप से बदल जाए.. लेकिन तथ्य यह है कि नए रनटाइम में अपग्रेड करने वाले लोगों को कुछ काम करना होगा। यह एक फैंसी यूआई में एक बटन पर क्लिक नहीं है और उनके लिए काम काट दिया है .. लेकिन साथ ही, मैं आपसे सहमत हूं कि नए ढांचे में अपग्रेड करना कई प्रकार के समूह को बदलने और बदलने से आसान होना चाहिए।

@FransBouma वह शायद कोई है जो मजबूत नामकरण की भी वकालत करता है।

@FransBouma @ phillip-haydon आपकी ट्रोलिंग को दूसरी जगहों पर ले जा सकते हैं, आप इस तरह से काम करने की उम्मीद नहीं कर सकते हैं और लोग आपको गंभीरता से लेंगे। यदि आपको कोई संदेह है तो मेरे ओपन सोर्स योगदान / परियोजनाओं पर एक नज़र डालें ... मुझे इससे निपटना होगा ... किसी भी तरह से ...

रिकॉर्ड के लिए मैं मजबूत नामकरण के खिलाफ हूं।

हालत से समझौता करो...

और आप कहते हैं कि मैं ट्रोलिंग कर रहा हूं?

" @FransBouma वह शायद कोई है जो मजबूत नामकरण की भी वकालत करता है।" विषय से हटकर है, और इस वार्ता के लिए बहुत उपयोगी नहीं है। हाँ ऐसा लगता है जैसे आपकी ट्रोलिंग..

इस चर्चा में विचार करने के लिए एक महत्वपूर्ण तथ्य यह है कि आईडीबी * इंटरफेस को एक दशक पहले .NET 2.0 में ADO.NET के लिए एपीआई के रूप में हटा दिया गया था जब बेस क्लास पेश किए गए थे। उन्हें बहिष्कृत चिह्नित नहीं किया गया था, लेकिन उस समय से निर्मित कुछ भी इसके बजाय आधार वर्गों पर निर्भर करता है। App.config प्रदाता और कनेक्शन स्ट्रिंग समर्थन दिमाग में आता है।

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

सरल, अपने स्वयं के प्रकार या आधार प्रकार को वापस करने के लिए अंतर्निहित पैकेज (आपका संगठन) को अपडेट करें जिसे उन्होंने 2.0 के बाद से समर्थित किया है। यदि आप .net के पुराने संस्करणों को लक्षित कर रहे हैं तो आप इसके बजाय इंटरफ़ेस को वापस करने के लिए निर्देश का उपयोग कर सकते हैं और इसे बहिष्कृत के रूप में चिह्नित कर सकते हैं।

यह एक सार्वजनिक एपीआई है, जिसका उपयोग हजारों अनुप्रयोगों द्वारा किया जाता है और एपीआई सार्वजनिक है और .net 1.0 के बाद से उपयोग में है। इसके विपरीत, यह 'सरल' नहीं है। हम सिर्फ एपीआई नहीं बदल सकते क्योंकि माइक्रोसॉफ्ट सोचता है कि हमारे जीवन को बेहतर बनाने के लिए उन्हें यही करना है: यह हमारे उपयोगकर्ताओं के लिए और इस प्रकार हमारे लिए एक बड़ा बोझ होगा।

हाँ यह बेकार है, लेकिन मुझे यकीन है कि उन्होंने (वास्तव में स्मार्ट व्यक्ति जो हर समय इस बारे में सोचते हैं) ने उस समय एक अच्छे कारण के लिए किया था (वापस .net 2.0 में)। क्या कोई बात हो सकती है और हो सकता है कि यह निश्चित रूप से बदल जाए.. लेकिन तथ्य यह है कि नए रनटाइम में अपग्रेड करने वाले लोगों को कुछ काम करना होगा। यह एक फैंसी यूआई में एक बटन पर क्लिक नहीं है और उनके लिए काम काट दिया है .. लेकिन साथ ही, मैं आपसे सहमत हूं कि नए ढांचे में अपग्रेड करना कई प्रकार के समूह को बदलने और बदलने से आसान होना चाहिए।

यही बात है: इसे 'नए रनटाइम' के रूप में नहीं देखा जाता है। अगर ऐसा होता, जैसा कि मैंने पहले ही चर्चा की है, तो यह कोई समस्या नहीं होगी। हालाँकि Microsoft का विचार है कि CoreFX लक्ष्यीकरण dll को .NET पूर्ण पर भी काम करना है, इसलिए कोई नया ढांचा नहीं है। .NET को लक्षित करने वाले पुस्तकालयों के अनुरक्षकों के लिए भी, कार्यक्षमता के साथ CoreFX में नहीं (इसलिए आज वहां बहुत सारे पुस्तकालय हैं) बहुत सारे 'मज़े' के लिए हैं क्योंकि उन्हें 2 संस्करण बनाए रखने होंगे। २ या ३ #ifdevs नहीं और समस्या हल हो गई है, लेकिन उनमें से कई। शायद यह आपके लिए अलग है क्योंकि आप शायद अपने क्लाइंट को उन घंटों के लिए बिल दे सकते हैं जो आपको एपीआई बदलने पर खर्च करने पड़ते हैं। जब आप एक सामान्य उद्देश्य प्रणाली बनाते हैं तो यह अलग होता है जिसका उपयोग कई लोग करते हैं।

यदि कॉम्पैक्ट फ्रेमवर्क समर्थन कोई दिशानिर्देश है, तो पूर्ण .net और CoreCLR पर ओआरएम का समर्थन करना एक भयानक समय सिंक होगा, बहुत निराशा होगी और वास्तव में वास्तव में बहुत अधिक लाभ नहीं होगा: आपको नई सुविधाएं नहीं मिलेंगी, आप केवल _absence_ के आसपास काम करते हैं .

(और इससे पहले कि कोई इसके साथ शुरू करे: "लेकिन यह लिनक्स पर चलता है, आप इसे हासिल करेंगे": हमारा सामान मोनो पर कई सालों से चलता है। तो नहीं, यह वास्तव में हासिल करने के लिए एक नई सुविधा नहीं है, यह पहले से ही था)।

सेलमीथिसफ्रेमवर्क। ओह, मैं भी क्यों परेशान हो रहा हूँ।

लेकिन उस समय से निर्मित कुछ भी इसके बजाय आधार वर्गों पर निर्भर करता है

_cough_ लिंक-टू-एसक्यूएल डेटा कॉन्टेक्स्ट _cough_

जैसा कि, वास्तव में, कई गैर-एमएस ओआरएम करते हैं, इसलिए समस्या है। डैपर के लिए हम बस थोड़ा सा
बुलेट और डीबीकनेक्शन में माइग्रेट हो गया। अगर हमारे पास फिर से समय होता, तो मैं
जब वे कुछ अप्रचलित करते हैं तो एमएस [अप्रचलित] का दृढ़ता से सुझाव देंगे। परंतु:
हम अतीत को नहीं बदल सकते।

यह _is_ हल करने के लिए एक बहुत ही दर्दनाक समस्या है, हालांकि, खासकर जब से अधिकांश
पुस्तकालय लेखकों को दोनों एपीआई के साथ जारी रखने की जरूरत है (एक तरह से संकलन
net40 आदि, और DNS के लिए दूसरा तरीका)। मैंने पहले गॉडफुल मेस पोस्ट किया था
वह डैपर ऐसा करने के लिए उपयोग करता है: यह सुंदर नहीं है, और यह उतना आसान नहीं है

अगर।

27 नवंबर 2015 20:07 को, "नतन वीवो" नोटिफिकेशन @github.com ने लिखा:

इस चर्चा में विचार करने के लिए एक महत्वपूर्ण तथ्य यह है कि आईडीबी*
एक दशक पहले .NET 2.0 में ADO.NET के लिए API के रूप में इंटरफेस को हटा दिया गया था
जब आधार वर्ग पेश किए गए थे। उन्हें बहिष्कृत के रूप में चिह्नित नहीं किया गया था, लेकिन
उस समय से निर्मित कुछ भी इसके बजाय आधार वर्गों पर निर्भर करता है।
App.config प्रदाता और कनेक्शन स्ट्रिंग समर्थन दिमाग में आता है।

यदि आपके पास उन इंटरफेस के आधार पर कोड है, तो आप a . के विरुद्ध कोडिंग कर रहे हैं
बहुत अप्रचलित एपीआई जिसमें एसिंक विधियों जैसी चीजों का कोई समर्थन नहीं है, जिसका अर्थ है
अगर आप चाहते हैं कि लोग इसका इस्तेमाल करते रहें, तो आपको इसे वैसे भी अपडेट करना होगा।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/dotnet/corefx/issues/3480#issuecomment -160198453।

मैं उस बिंदु को देखने में विफल हूं कि इंटरफेस का उपयोग करने के परिणामस्वरूप एसिंक विधियों को जोड़ा नहीं जा सका। आप async विधियों के लिए नए इंटरफ़ेस बना सकते थे। IAsyncDbCommand , IAsyncDataReader आदि। फिर आप आधार वर्गों को दोनों प्रकार के इंटरफेस को लागू कर सकते हैं।

ADO.NET उपयोगकर्ता या तो async संस्करण या सिंक्रोनस संस्करण का उपयोग कर रहे हैं, दोनों का नहीं। तो यह बहुत अच्छा काम करता।

पुस्तकालय डेवलपर्स के लिए यह वास्तव में कोई फर्क नहीं पड़ता कि कार्यक्षमता बढ़ती है और इंटरफेस वही रहता है। क्या वह उद्देश्य नहीं है? नई कार्यक्षमता के लिए नए इंटरफेस पेश करें। बेस क्लास के साथ काम करना सिर्फ एक दर्द है।

क्या मैं यहाँ सूत्र को संक्षेप में प्रस्तुत कर सकता हूँ?

.NET डेटा टूलिंग पर कई स्वतंत्र स्वीकृत समुदाय विशेषज्ञ,
कई ओआरएम लेखकों और अनुरक्षकों सहित आपको बता रहे हैं - काफी
स्पष्ट रूप से - कि यह समस्याओं के एक महत्वपूर्ण समूह का प्रतिनिधित्व करता है। मुझे नहीं लगता
हम में से कोई भी सूक्ष्मताओं से अनभिज्ञ है, या प्रोग्रामिंग के भोले हैं
सिद्धांत, और अधिकांश यदि हम सभी पिछली कहानी को ठीक से नहीं जानते हैं,
क्योंकि हम उस समय वहां थे।

आधिकारिक प्रतिक्रिया प्रतीत होती है "यह हमें ठीक लगता है, और ईएफ खुश है"।
हाँ, हम यह जानते हैं, क्योंकि निर्णय पहले स्थान पर किया गया था।

ठीक है, हम सभी ने अपनी राय व्यक्त की है, भले ही वह फलदायी न हो।
27 नवंबर 2015 को 20:41 पर, "जोनास गौफिन" नोटिफिकेशन @github.com ने लिखा:

मैं उस बिंदु को देखने में विफल रहता हूं कि async विधियों को a . के रूप में नहीं जोड़ा जा सकता है
इंटरफेस का उपयोग करने का परिणाम। आप के लिए _new_ इंटरफेस बना सकते थे
एसिंक विधियाँ। IAsyncDbCommand, IAsyncDataReader आदि। तब आप कर सकते थे
आधार वर्ग दोनों प्रकार के इंटरफेस को लागू करें।

ADO.NET उपयोगकर्ता या तो async संस्करण या तुल्यकालिक का उपयोग कर रहे हैं
संस्करण, दोनों नहीं। तो यह बहुत अच्छा काम करता।

पुस्तकालय डेवलपर्स के लिए यह वास्तव में कोई फर्क नहीं पड़ता कि कार्यक्षमता बढ़ती है और
इंटरफेस वही रहते हैं। क्या वह उद्देश्य नहीं है? नया परिचय दें
नई कार्यक्षमता के लिए इंटरफेस। बेस क्लास के साथ काम करना सिर्फ एक दर्द है।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/dotnet/corefx/issues/3480#issuecomment -160201361।

दोस्तों .. अपना कोड अपडेट करें और अपने प्रमुख संस्करण को टक्कर दें। किया हुआ।

हां, लेकिन ऐसा कोई कारण नहीं है कि आप कोर को लक्षित करते समय उस इंटरफ़ेस को कंपाइलर निर्देश के साथ पॉलीफ़िल नहीं कर सकते। मैंने अपने कुछ पीसीएल पैकेजों के साथ ऐसा किया है।

मुझे लगता है कि माइक्रोसॉफ्ट को यह दोहराने की जरूरत है कि कोर डॉट नेट फुल नहीं है, लेकिन यह अभी भी मदद नहीं करता है .. मुझे लगता है कि माइक्रोसॉफ्ट को ईमानदार होने के लिए कुछ इंटरफेस को साफ करने की जरूरत है। हाल ही में एक ब्लॉग पोस्ट चल रहा था जहां बहुत असंगत इंटरफेस हैं और आप कभी नहीं जानते कि कौन सा चुनना है .. मुझे लगता है कि दूसरे एसिंक इंटरफ़ेस को परिभाषित करना बेकार है। अच्छा होगा अगर सब कुछ async होता ..

अच्छा होगा यदि पूर्ण ढांचे को यह सुनिश्चित करने के लिए चला गया था कि जिन चीजों को बहिष्कृत के रूप में चिह्नित करने की आवश्यकता है वे हैं ... और 4.6.2 के रूप में जारी किया गया

@mgravell +100। सही कहा, 100% सहमत।

वास्तव में कितना प्रभावित है? हम यहां coreclr के बारे में बात कर रहे हैं? .NET डेस्कटॉप आने वाले कई वर्षों तक जीवित रहेगा जब तक coreclr पकड़ में नहीं आ जाता। वास्तव में शिकायत करने वालों के लिए, आप यहां क्या नुकसान पहुंचाते हैं? बहुत से लोग मूल रूप से कह रहे हैं कि यह दुनिया का अंत है।

@leppie दरअसल, यह कई सालों तक रहेगा। और हमें आने वाले वर्षों के लिए भी इन हैक्स और वर्कअराउंड को अपने कोड में बनाए रखना होगा। यहां विवाद का विषय दोनों के बीच साझा पुल को हटाना है। उस कार्यभार को बीसीएल के बजाय सभी पुस्तकालय डेवलपर्स पर स्थानांतरित कर दिया गया है। मैं इंटरफ़ेस के पेशेवरों और विपक्षों के दोनों पक्षों को समझता हूं, लेकिन मुझे यहां कुछ लोगों से "यह मामूली है, आगे बढ़ें" रवैया समझ में नहीं आता है।

आइए यहां कुंद हों: यदि पुस्तकालय उपभोक्ताओं को सभी को एक ही काम करना है, तो यह बीसीएल में होना चाहिए । बहस यह है कि "यह क्या रूप लेता है?"

इंटरफेस को हटाने के साथ-साथ, अब नए पैकेजिंग मॉडल के साथ एक _additional_ वर्जनिंग तंत्र है: एक्स, वाई और जेड में कौन सी कक्षाएं उपलब्ध हैं, अब टूलिंग द्वारा समर्थित बेहतर है। जैसे dotnet5.2 बनाम 5.4 वर्तमान में। लेकिन फिर वहां भी कमियां हैं। उदाहरण के लिए SqlClient अभी भी इंटरफेस को लागू करने के बिंदु पर नहीं है क्योंकि यह आज भी खड़ा है (डॉटनेट/रनटाइम # 14302 और डॉटनेट/रनटाइम # 15269) देखें, और जो दिया @YoungGah ने कहा (जब तक कि मैं गलत

तो 5.6 (1.5) के साथ क्या होता है? यदि अधिक सदस्यों को अमूर्त वर्गों में जोड़ा जाता है तो प्रत्येक डेटा प्रदाता से गतिमान लक्ष्य के साथ तालमेल रखने की अपेक्षा की जाती है जो प्रत्येक गतिशील व्यक्ति के साथ बदल सकता है? प्रत्येक उपभोक्ता को प्रत्येक में उपलब्ध सुविधाओं पर एक संस्करण निर्धारण करने की आवश्यकता है? हमें कक्षा के सार आधार से मेल खाने के लिए आगे बढ़ने वाले मंच के प्रत्येक संस्करण के लिए असेंबली के एक संस्करण को संकलित करने की आवश्यकता है? अतिरिक्त के साथ आगे बढ़ने पर यह सब कैसे काम करता है यह 100% स्पष्ट नहीं है। एक इंटरफ़ेस जो नहीं बदल रहा है वह कहीं अधिक स्पष्ट है। इसके शीर्ष पर प्रलेखन है: कौन सी सुविधाएँ, विधियाँ आदि उपलब्ध हैं, जिनमें से संस्करण _और प्लेटफ़ॉर्म_ आगे बढ़ने वाले सभी पुस्तकालय लेखकों के लिए एक बहुत बड़ा दर्द बिंदु होने जा रहे हैं। वह चिंता यहाँ केवल अर्ध-संबंधित है, लेकिन यह खेल में है।

अभी के लिए, मैं उत्सुकता से अगले 2 सप्ताह में अपडेट का इंतजार कर रहा हूं। मेरा डर यह है कि यह प्रभावी रूप से होगा, जैसा कि पूरे समय संदेश रहा है: "हम एक्स कर रहे हैं क्योंकि यह एसक्यूएल और एंटिटी फ्रेमवर्क के लिए काम करता है, और यह काफी अच्छा है" - उन शब्दों में से किसी का उपयोग किए बिना। पुस्तकालय लेखक की ओर से, मेरे लिए, इन मोर्चों पर महीनों से प्रगति (कोड और चर्चा दोनों में) की कमी रही है।

100% सहमत।

जब मैंने SqlFu (मेरा माइक्रो ORM) का v2 (और ऊपर) डिज़ाइन किया है, तो मुझे यह तय करना था कि एक्सटेंशन विधियों को कहाँ संलग्न करना है: DbConnection/DbCommand या इंटरफेस के लिए। मैंने यह पाया और मैंने अमूर्त कक्षाओं के लिए जाने का फैसला किया है।

इसलिए, मैं इससे प्रभावित नहीं हूं, हालांकि मैं IDataReader हटाने से प्रभावित हूं, क्योंकि एमएस ने अपने ज्ञान में यह स्पष्ट नहीं करने का फैसला किया कि कौन से इंटरफेस को अप्रचलित माना जाना चाहिए और कौन सा नहीं। लेकिन मेरे मामले में, इंटरफ़ेस को बदलना मुश्किल नहीं है।

हालांकि, मुझे समर्पित इंटरफेस होने का मूल्य दिखाई देता है और मुझे नहीं लगता कि एमएस के लिए उन्हें वापस रखना/जोड़ना मुश्किल है। अगर वे तय करते हैं कि पुराने इंटरफेस इतनी अच्छी तरह से डिज़ाइन नहीं किए गए हैं, तो ठीक है! नए लोगों को अधिक विशिष्ट होने के लिए डिज़ाइन करें। कम से कम भविष्य में हमें उसी समस्या से नहीं जूझना पड़ेगा।

(यह यूएस में थैंक्सगिविंग वीक है, इसलिए Microsoft द्वारा प्रतिक्रियाएँ तब तक बहुत सीमित होंगी जब तक वे अगले सप्ताह कार्यालय में वापस नहीं आ जाते)

बस दोहराना चाहते हैं - ताकि इस धागे में कोई अच्छा सुझाव/बग न खोएं, यदि आपके पास वर्तमान आधार वर्गों/सतह क्षेत्र के साथ समस्याएं हैं, और/या जिस तरह से वे संस्करण आगे बढ़ रहे हैं, तो कृपया एक नया मुद्दा दर्ज करें, इस चर्चा को केवल v1 इंटरफेस के बारे में ही रहने दें।

@NickCraver .NET फ्रेमवर्क के संस्करण-से-संस्करण संगतता के समान, .NET कोर सतह क्षेत्र के संस्करणों के बीच कोई ब्रेकिंग परिवर्तन नहीं होगा। उदाहरण के लिए, आधार वर्ग में सार सदस्यों को जोड़ना उस परिवर्तन का उदाहरण होगा जो _नहीं किया जाएगा।

@davkean आप कितने आश्वस्त हैं कि ऐसा नहीं होगा? यह देखते हुए कि हम एक अधूरा सतह क्षेत्र देख रहे हैं और कोई गारंटी नहीं है कि यह बदलेगा, यह विश्वास करना कठिन है कि लापता टुकड़े बाद में दिखाई नहीं देंगे यदि बिल्कुल भी। हालांकि, मुझे लगता है कि कोई भी ब्रेकिंग परिवर्तन एक _more_ महत्वपूर्ण बात नहीं है, जो मुझे यकीन है कि यहां अधिकांश पुस्तकालय लेखक भी मान लेंगे। इसका मतलब है कि यह और भी महत्वपूर्ण है कि आरटीएम हिट होने से पहले इन वस्तुओं का अच्छी तरह से ध्यान रखा जाता है।

रिकॉर्ड के लिए सतह क्षेत्र पर अलग-अलग मुद्दों को दर्ज किया गया है, क्रमशः 25 सितंबर और 2 अक्टूबर को माइक्रोसॉफ्ट से नवीनतम अपडेट के साथ डॉटनेट/रनटाइम#14302 और डॉटनेट/रनटाइम#15269 देखें - उसके बाद कई बार अपडेट और गतिविधि मांगने के बावजूद। यानी 2 महीने और 2 रिलीज़ जो चल चुकी हैं, चुप्पी के साथ। यह इस रेपो में सबसे सक्रिय मुद्दा होने

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

@NickCraver क्षमा करें, हम यहां बुरी तरह से कर रहे हैं - इन मुद्दों को भुलाया नहीं गया है, @YoungGah ने उनके बारे में ऊपर एक अपडेट प्रदान किया है, मैं सुनिश्चित करूंगा कि वह प्रगति के साथ मुद्दों को अपडेट करे। बहुत सारे MS अभी भी _खुली चीज़ में काम करने के लिए अभ्यस्त हो रहे हैं, यह समय के साथ बेहतर होता जाएगा - हमें इस पर कॉल करने के लिए धन्यवाद।

@niemyjski

dnx पूरी तरह से नया ढांचा/रनटाइम है

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

अगर इसमें कुछ इंटरफेस नहीं हैं तो इसके साथ सौदा करें ... एक कंपाइलर निर्देश के साथ।

हां, लेकिन ऐसा कोई कारण नहीं है कि आप कोर को लक्षित करते समय उस इंटरफ़ेस को कंपाइलर निर्देश के साथ पॉलीफ़िल नहीं कर सकते।

यदि आपने इस धागे में उड़ान भरने से पहले टिप्पणियों को पढ़ने की जहमत उठाई है, तो आपको पता चल जाएगा कि a) इसके कारण हैं और b) यह कोर BCL इंटरफेस के लिए एक टूटी-फूटी रणनीति है।

@nvivo

इस चर्चा में विचार करने के लिए एक महत्वपूर्ण तथ्य यह है कि आईडीबी * इंटरफेस को एक दशक पहले .NET 2.0 में ADO.NET के लिए एपीआई के रूप में हटा दिया गया था जब बेस क्लास पेश किए गए थे।

अगर ऐसा होता तो आप एक दशक पहले बेस क्लास द्वारा बहिष्कृत किए गए इंटरफेस का उपयोग करने के लिए उन्हें वापस जाने के लिए कहने के लिए कोई मुद्दा नहीं खोलते थे। जिस तरह से आप एक एपीआई को संवाद करते हैं, वह [Obsolete] विशेषता का उपयोग करना है जो मौजूदा के लिए इसका एकमात्र उद्देश्य है। यदि इसे व्यापक रूप से संप्रेषित नहीं किया जाता है, तो इस बात पर ध्यान दिए बिना कि आपके विचार अब क्या हैं, इसे बहिष्कृत नहीं किया जाता है। तथ्य यह है कि अधिकांश गैर-एमएस .NET ओआरएम उन पर निर्भर हैं, एक संकेत देना चाहिए कि इसका बहिष्करण खराब संचार किया गया था, यदि बिल्कुल भी।

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

एक झूठा स्ट्रॉमैन - एक का मतलब दूसरे से नहीं है। हमने पहले ही async API के लिए समर्थन जोड़ दिया है, और नहीं, उन्हें जोड़ने से मौजूदा ग्राहक कोड-आधार नहीं टूटे और न ही किसी मौजूदा API को बदलने की आवश्यकता हुई।

ठीक है, यह पूरी तरह से एक साफ शुरुआत की बात है, लेकिन क्या मैं एक प्रश्न पूछ सकता हूं: आपके अपने ढांचे का समर्थन करने के लिए क्या समझौता किया गया है? अतीत की कौन सी भयावहताएं माइग्रेट की गई हैं क्योंकि उन्हें एंटिटी फ्रेमवर्क चलाने की आवश्यकता है?

माइक्रोओआरएम गायब हो जाना शर्म की बात होगी, वे नेट कोड को कुछ हद तक प्रदर्शनकारी बनाते हैं (ईएफ उन अनुप्रयोगों के लिए अनुपयोगी जानवर है जहां कुछ पंक्तियों को लोड करने के लिए 500ms स्वीकार्य नहीं है)।

इंटरफेस बनाम बेस क्लास के लिए: बेस क्लास तब तक महान होते हैं जब तक कि जो कुछ भी पुन: उपयोग किया जा सकता है वह वर्चुअल है। उदाहरण के लिए डब्ल्यूसीएफ में सबसे अधिक परेशान करने वाले डिजाइन निर्णयों में से एक सीलबंद कक्षाओं का प्रचुर उपयोग है जिसमें बहुत अधिक कार्यक्षमता होती है। मान लें कि आपको एक्सएमएल संदेशों को संभालने के तरीके में एक छोटा सा बदलाव करना है (क्योंकि: इंटरऑप)। एक छोटे से फ़ंक्शन को इनहेरिट करने और ओवरराइड करने के बजाय, आपको फिर से लागू करना होगा। WCF उदाहरण में SOLID में S को छोड़ दिया गया था, इसलिए आप आमतौर पर एक बड़े इंटरफ़ेस को लागू करना छोड़ देते हैं, जिसमें से कोई भी परीक्षण यह सुनिश्चित करने के लिए आवश्यक नहीं है कि यह उत्पादन गुणवत्ता का हो।

तो: आधार वर्ग जिसे हम अनुकूलित कर सकते हैं वह अच्छी बात है।

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

@davkean गारंटी देना असंभव है, और आप इसे जानते हैं। ADO.NET विभिन्न प्रकार की विशेषताओं के साथ तृतीय पक्ष सॉफ़्टवेयर के साथ संचार करने के लिए एक सबसिस्टम है, जो कुछ विस्तार बिंदुओं के साथ एक सामान्य एपीआई के माध्यम से सामने आता है। चीजें बदलती हैं, यहां तक ​​​​कि डेटाबेस-भूमि में भी, और इन बाहरी डेटाबेस सेवाओं को संचार और उपभोग करने के लिए उपयोग किए जाने वाले एपीआई के माध्यम से ये परिवर्तन तरंगित होते हैं। इसके अलावा: व्यवहार में परिवर्तन _is_ भी एक महत्वपूर्ण परिवर्तन है। और हमने पिछले वर्षों में उन्हें ADO.NET (उदाहरण के लिए त्रुटि प्रबंधन के बारे में) में भी देखा है।

संपूर्ण ADO.NET API उन परिवर्तनों के दुष्प्रभावों से भरा हुआ है, जो अक्सर SQL सर्वर द्वारा संचालित होते हैं; ऐसा शायद ही कभी हुआ हो कि चीजों को सामान्य रूप से डिजाइन किया गया था और फिर SQL क्लाइंट में स्थानांतरित कर दिया गया था, लेकिन दूसरी तरफ (उदाहरण के लिए कई नहीं हैं, यदि कोई हो, बेस क्लास में विशेषताएं जिन्हें एसक्ल क्लाइंट द्वारा अनदेखा किया जाता है)। इसमें जोड़ा गया कि तीसरे पक्ष द्वारा आवश्यक चीजों को एपीआई में कभी नहीं बनाया गया।

तो संक्षेप में, यह एक एपीआई है कि, शुरुआत में .NET 1.0 के साथ एक सामान्य डिजाइन था (जो कई क्षेत्रों में गंभीर रूप से त्रुटिपूर्ण साबित हुआ) और तब से परिवर्तनों से निपटने के लिए बाएं और दाएं सुविधाओं के साथ समझौता किया गया था परिदृश्य। उनमें से _अधिकांश_ अभी भी एपीआई में हैं (यदि सभी नहीं हैं)। और अब माइक्रोसॉफ्ट एक को हटा देगा: इंटरफेस।

एपीआई के एक यादृच्छिक टुकड़े को हटाकर पूरी तरह से _nothing_ प्राप्त नहीं हुआ है: इसके माध्यम से कोई सुविधा नहीं जोड़ी जाती है (उदाहरण के लिए आप यहां वापस धक्का देने के बजाय उस पर समय बिता सकते हैं), लेकिन कोड जो एपीआई _will_ के उस टुकड़े पर काम नहीं करता है। यदि इस सारे पनीर को हिलाने के पीछे का बिंदु 'शुरू करना' है, तो हर तरह से करें, लेकिन इसे एक वास्तविक सामान्य उद्देश्य एपीआई बनाने के लिए एपीआई को नया स्वरूप देकर करें, _all_ से छुटकारा पाएं जो वर्षों से ढेर हो गया है .

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

यदि Microsoft आधार वर्गों के माध्यम से नई कार्यक्षमता जोड़ सकता है, तो तृतीय पक्ष प्रदाता स्वचालित रूप से 'एक रूप' को लागू करते हैं (जैसे Async के साथ, जहां async विधि वापस सिंक विधि पर आती है यदि प्रदाता इसे लागू नहीं करता है), बढ़िया: वह इसका मतलब है कि हम तीसरे पक्ष के ओआरएम डेवलपर्स हैं (और इसका सामना करते हैं: कई डेवलपर्स तीसरे पक्ष (माइक्रो) ओआरएम के कोड के माध्यम से _your_ एपीआई तक पहुंचते हैं) बस एक वर्ग को लक्षित कर सकते हैं और वह यह है।

लेकिन इसकी गारंटी नहीं है कि आप ऐसा करेंगे। उदाहरण के लिए Microsoft के भीतर किसी ने भी Oracle या PostgreSql को ADO.NET में जोड़ने के लिए विशिष्ट सुविधाओं से कभी परेशान नहीं किया। उदाहरण के लिए UDTs का उपयोग, दस्तावेज़ ट्री, कर्सर के माध्यम से कई परिणाम, प्रत्येक ADO.NET प्रदाता को इन सुविधाओं से निपटने का अपना तरीका खोजना होगा। क्या होगा अगर (कब?) SQL सर्वर को एक दस्तावेज़ ट्री सुविधा मिलती है जैसे कि JSON डॉक्स के साथ, क्या ADO.NET को उसके लिए एक नए एपीआई के साथ अपडेट किया जाएगा? जैसा आपने अतीत में ADO.NET प्रदाताओं से त्रुटि रिपोर्टिंग के साथ किया है?

आप इस तरह की गारंटी नहीं दे सकते हैं, और यहां यह बताना नासमझी है कि MS भविष्य में कुछ भी नहीं तोड़ेगा। उनके पास हमेशा होता है और कभी-कभी उन्हें भी करना पड़ता है: आखिरकार हर एपीआई में खामियां होती हैं, और ADO.NET उनमें से भरा होता है; किसी न किसी दिन कोई न कोई उन्हें 'ठीक' कर देगा।

तो, संक्षेप में: इंटरफेस ADO.NET का हिस्सा हैं और साथ ही एपीआई में कहीं और टूटे हुए हिस्से ADO.NET का हिस्सा हैं। एपीआई को ठीक करने के लिए उन्हें हटाया नहीं गया है, न ही एपीआई को इसे और अधिक सामान्य उद्देश्य एपीआई बनाने के लिए दोबारा प्रतिक्रिया दी गई है: इसे छोड़ दिया गया है, कुछ तत्वों जैसे डेटासेट/टेबल तत्वों को हटा दिया गया है क्योंकि इन्हें पोर्ट नहीं किया गया है (और वहां अन्य मुद्दे हैं जो इसी तरह की प्रगति के साथ बहस कर रहे हैं), सिवाय ... इंटरफेस हटा दिए गए हैं।

केवल उस दृष्टि से इसका पहले से ही कोई अर्थ नहीं है।

@mythz

अगर ऐसा होता तो आप उन्हें उन इंटरफेस का उपयोग करने के लिए वापस जाने के लिए कहते हुए एक मुद्दा नहीं खोलते जिन्हें आप जानते थे कि उन्हें बहिष्कृत कर दिया गया था

आप संभवतः ओपी को पढ़ और समझ नहीं सकते। ये चर्चाएँ बहुत अधिक धार्मिक होती जा रही हैं और आप केवल ऐसी बातें मान रहे हैं जो किसी ने नहीं कही।

मैंने इस मुद्दे को खोला क्योंकि मेरा मानना ​​​​है कि एपीआई का वर्णन करने और परीक्षण में मदद करने के लिए इंटरफेस बेहतर हैं। अगर ऐसा हो जाता है, तो मुझे नहीं लगता कि उन्हें 15 साल पुराने एपीआई के साथ संगत होना चाहिए, जिसमें इसके मुद्दे थे। जब तक आप लोग चर्चा को उस पर नहीं ले जाते, तब तक बैकवर्ड संगतता इस मुद्दे में एक बिंदु नहीं थी।

ऐसा नहीं है कि मेरा मानना ​​है कि सिर्फ इसके लिए चीजें टूटनी चाहिए। लेकिन इंटरफ़ेस वर्जनिंग अतीत की समस्या है। यदि कोरएफएक्स प्रमुख संस्करणों के बीच कुछ बदलता है, तो इसके अपेक्षित प्रमुख संस्करणों में ब्रेकिंग बदलाव होंगे। यदि वे छोटे संस्करणों के बीच एक इंटरफ़ेस तोड़ते हैं, तो यह सिर्फ ढिलाई है।

हम पहले ही async API के लिए समर्थन जोड़ चुके हैं

आप सिंक एपीआई के शीर्ष पर एक एसिंक एपीआई नहीं जोड़ सकते हैं। यदि आपने IDbConnection या IDbCommand का उपयोग करके ऐसा किया है, तो आपने इसे गलत किया है। यदि आप इन इंटरफेस का उपयोग नहीं कर रहे हैं, तो आपके पास वास्तव में उनके साथ किसी भी पश्चगामी संगतता का बचाव करने का कोई मतलब नहीं है।

हम पहले ही async API के लिए समर्थन जोड़ चुके हैं

आप सिंक एपीआई के शीर्ष पर एक एसिंक एपीआई नहीं जोड़ सकते हैं। यदि आपने IDbConnection या IDbCommand का उपयोग करके ऐसा किया है, तो आपने इसे गलत किया है। यदि आप इन इंटरफेस का उपयोग नहीं कर रहे हैं, तो आपके पास वास्तव में उनके साथ किसी भी पश्चगामी संगतता का बचाव करने का कोई मतलब नहीं है।

ADO.NET में उन्होंने यही किया: डिफ़ॉल्ट रूप से Async विधियाँ सिंक वेरिएंट पर वापस आती हैं। इस तरह सभी ADO.NET प्रदाता जो Async का समर्थन नहीं करते हैं (पढ़ें: इस समय SqlServer को छोड़कर उन सभी को) उन चीजों को लागू करने की आवश्यकता नहीं है जिनका वे समर्थन नहीं करते हैं: ORM में तृतीय पक्ष कोड जो Async api की पेशकश करता है, उसके विरुद्ध प्रोग्राम कर सकता है ADO.NET में Async विधियाँ और यदि ado.net प्रदाता async का समर्थन नहीं करता है, तो वास्तव में किसी को पता नहीं चलेगा। ठीक है ... आपको पता चल जाएगा क्योंकि यह धीमा है, लेकिन एक तरफ।

अब यह ADO.NET के भीतर किसी भी 'डिज़ाइन' या सामान्य वास्तुकला की अनुपस्थिति का भी एक अच्छा उदाहरण है: सामान्य एपीआई में लेनदेन संबंधी बचत बिंदु बनाने का _no_ तरीका है। हालांकि लगभग _all_ डेटाबेस DbTransaction से अपने व्युत्पन्न वर्ग पर 'सहेजें (स्ट्रिंग)' विधि के साथ इसका समर्थन करते हैं। OleDbTransaction को छोड़कर सभी (जैसा कि एमएस एक्सेस इसका समर्थन नहीं करता है, कम से कम यह मेरा संदेह है)।

यह आसान नहीं है, लेकिन किसी ने इसे आसान नहीं कहा। यह समस्या नई नहीं है, ओलेडीबी और ओडीबीसी ने कई सालों से इससे निपटा है, जेडीबीसी ने इसे हल करने का एक तरीका ढूंढ लिया है, माइक्रोसॉफ्ट को इस तरह की चीजों को दूर करने के लिए पहिया का पुन: आविष्कार करने की आवश्यकता नहीं है। यह डीबी दायरे के लिए भी अद्वितीय नहीं है: उदाहरण के लिए प्रत्येक वीडियोकार्ड अपने एपीआई के माध्यम से सुविधाओं के एक अलग सबसेट का समर्थन करता है, जिसे डायरेक्ट 3 डी/एक्स के माध्यम से डेवलपर के सामने उजागर किया जाता है। यह वास्तव में दिलचस्प है कि इन अन्य दुनियाओं में डिज़ाइन कैसे चलते हैं: एपीआई डिज़ाइन किया गया है, और जिन पार्टियों को इसका समर्थन करने की आवश्यकता है (जेडीबीसी ड्राइवर, ओलेडीबी ड्राइवर लेखक इत्यादि) को इन्हें लागू करना होगा। आपका ड्राइवर X को सपोर्ट नहीं करेगा? आपका ड्राइवर X के अनुरूप नहीं है। "Oracle ADO.NET v10 का समर्थन नहीं करता है"। Oracle के भीतर कोई भी इसे पढ़ना नहीं चाहता है। इसके बजाय SqlClient लीड है, और वैगन से जो गिरता है उसे ADO.NET में जोड़ा जाता है और बस।

ADO.NET में उन्होंने यही किया: डिफ़ॉल्ट रूप से Async विधियाँ सिंक वेरिएंट पर वापस आती हैं।

नहीं, ऐसा नहीं है। एपीआई एसिंक विधियों को उजागर करता है जो डिफ़ॉल्ट रूप से सिंक विधियों पर वापस आते हैं, लेकिन प्रदाता वास्तविक एसिंक्स संचालन के साथ ओवरराइड करते हैं। @mythz क्या कह रहा है कि वह IDbCommand और IDbConnection का उपयोग कर रहा है और ऐसा कर रहा है।

यह संभव नहीं है, अवधि। यदि आप इसे करते हैं, तो आप या तो इसे सही नहीं कर रहे हैं या आप इंटरफ़ेस का उपयोग नहीं कर रहे हैं। यदि अंतर्निहित एपीआई एसिंक नहीं है तो आप एसिंक का आविष्कार नहीं कर सकते हैं।

नहीं, ऐसा नहीं है। एपीआई एसिंक विधियों को उजागर करता है जो डिफ़ॉल्ट रूप से सिंक विधियों पर वापस आते हैं, लेकिन प्रदाता वास्तविक एसिंक्स संचालन के साथ ओवरराइड करते हैं। @mythz क्या कह रहा है कि वह IDbCommand और IDbConnection का उपयोग कर रहा है और ऐसा कर रहा है।

कोई भी आधिकारिक प्रदाता ऐसा नहीं करता है कि SqlClient को छोड़कर, अन्य सभी, जैसे ODP.NET, async कोड के किसी भी रूप को लागू नहीं करते हैं और इस प्रकार कॉलिंग कोड सिंक वेरिएंट (DbDataReader/DbCommand आदि में async विधियाँ जो वास्तव में सिंक कोड निष्पादित करते हैं) पर वापस आ जाते हैं। ) इसलिए उपयोगकर्ता कोड एक एसिंक वैरिएंट को कॉल करता है, जो सिंक ऑपरेशंस करने वाले हुड के तहत है। जिसके परिणामस्वरूप अभ्यास में कोई एसिंक नहीं किया जा रहा है (जैसा कि सभी कोड अभ्यास में बस सिंक है)। शायद देवर्ट के प्रदाता अपने स्वयं के कार्यान्वयन में एक एसिंक एपीआई लागू करते हैं, निश्चित नहीं।

वैसे भी, यह सही करने के बारे में नहीं है, यह एपीआई के संस्करण के बारे में है।

@nvivo

मैंने इस मुद्दे को खोला क्योंकि मेरा मानना ​​​​है कि एपीआई का वर्णन करने और परीक्षण में मदद करने के लिए इंटरफेस बेहतर हैं। अगर ऐसा हो जाता है, तो मुझे नहीं लगता कि उन्हें 15 साल पुराने एपीआई के साथ संगत होना चाहिए, जिसमें इसके मुद्दे थे। जब तक आप लोग चर्चा को उस पर नहीं ले जाते, तब तक बैकवर्ड संगतता इस मुद्दे में एक बिंदु नहीं थी।

ठीक है, तो आप जानते थे कि कोर ADO.NET इंटरफेस को 10 साल पहले बहिष्कृत कर दिया गया था, सब कुछ बेस क्लास में स्थानांतरित हो गया था, फिर भी आपने सोचा था कि उन्हें अभी इसे छोड़ देना चाहिए और इंटरफेस पर वापस जाना चाहिए, संयोग से मौजूदा इंटरफेस के समान नामों का उपयोग करना चाहिए, लेकिन मौजूदा इंटरफेस अब मौजूद नहीं होना चाहिए, क्योंकि पश्च-संगतता की आवश्यकता नहीं है? ज़रूर, कानूनी लगता है।

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

आप सिंक एपीआई के शीर्ष पर एक एसिंक एपीआई नहीं जोड़ सकते हैं। यदि आपने IDbConnection या IDbCommand का उपयोग करके ऐसा किया है, तो आपने इसे गलत किया है। यदि आप इन इंटरफेस का उपयोग नहीं कर रहे हैं, तो आपके पास वास्तव में उनके साथ किसी भी पश्चगामी संगतता का बचाव करने का कोई मतलब नहीं है।

मेरी इच्छा है कि आप उन चीजों पर टिप्पणियों के साथ इस धागे को प्रदूषित करना बंद कर दें जिनके बारे में आपको स्पष्ट रूप से जानकारी नहीं है। स्रोत कोड पढ़ें यदि आप जानना चाहते हैं कि Async API कैसे लागू किया जाता है - और आँख बंद करके झूठ फैलाना बंद करें। किसी तृतीय पक्ष लाइब्रेरी के लिए System.Data इंटरफेस का विस्तार करना असंभव है। हम एक कार्यान्वयन-अज्ञेय एपीआई प्रदान करते हैं जो प्रत्येक प्रमुख आरडीबीएमएस का समर्थन करने के लिए, न्यूनतम निर्भरता को उजागर करता है जो प्रत्येक एडीओ.नेट प्रदाता अपने बाहरी फेसिंग एपीआई - अर्थात् कोर सिस्टम। डेटा इंटरफेस में लागू करता है। Async API, IDbConnection के विस्तार के तरीके हैं, जो पर्दे के पीछे के ठोस ADO.NET प्रदाताओं पर async API का लाभ उठाते हैं जिनके पास उनके लिए समर्थन है। आंतरिक रूप से प्रत्येक समर्थित ADO.NET प्रदाता पर पहले से ही ठोस निर्भरताएँ मौजूद हैं, भले ही async समर्थन कुछ भी हो। आपका सुझाव है कि हमारे पास "वास्तव में उनके साथ किसी भी पिछली संगतता का बचाव करने का कोई मतलब नहीं है" अनुभवहीन और पूरी तरह से निराधार है।

मुझे इसे बाड़ के Microsoft पक्ष (cc @davkean @YoungGah) से पूछने दें: मान लें कि यह एक आदर्श दुनिया है और कभी कुछ नहीं हुआ। कब _do_ आप चीजों को तोड़ना चाहते हैं? 6.0 जैसे प्रमुख संस्करण? फिर कभी? इंटरफेस के खिलाफ तर्क यह है कि वे संस्करण नहीं हैं। ठीक है, यह मान्य है - लेकिन _अगर हम अमूर्त वर्गों को नहीं बदल रहे हैं_, तो यह भी एक महत्वपूर्ण मुद्दा है। तो...क्या हम वहां कुछ स्पष्टता प्राप्त कर सकते हैं?

जांच करना:
यदि उत्तर हाँ है (आरटीएम के बाद कुछ बिंदु पर परिवर्तन होंगे), तो हम किस प्रकार के विराम देखेंगे? जोड़, नए तरीके? यदि मुझे अपने प्रदाता के लिए आधार वर्ग विरासत में मिला है तो क्या होता है जब आप लोगों द्वारा उपयोग की जा रही परस्पर विरोधी पद्धति आदि को जोड़ते हैं?

अगर उत्तर नहीं है (कभी नहीं): क्यों न केवल इंटरफेस को वापस जोड़ें?

यह धागा _right now_ पर चर्चा करने पर थोड़ा लटका हुआ है - जो कि ज्यादातर अच्छी बात है क्योंकि इस सामान को ASAP को ठीक करने की आवश्यकता है। यहां का हर पुस्तकालय लेखक जानता है कि रिलीज होने के बाद कुछ भी हासिल करना कितना कठिन है, और यही कारण है कि हम इतनी मेहनत करते हैं। दुर्भाग्य से, _future_ परिवर्धन और परिवर्तनों के लिए एक स्पष्ट योजना की कमी, यदि कोई हो, तो अधिक जानकारीहीन तर्क देता है।

भविष्य के लिए क्या योजनाएं हैं?

हमें इस मामले में अमूर्त वर्गों के माध्यम से कार्यान्वयन को मजबूर नहीं करना चाहिए। आईएमओ

Microsoft ऐसे परिवर्तन नहीं करेगा जो .NET 4.5 के लिए टूट रहे हैं। यह विंडोज का हिस्सा है। अनुकूलता राजा है।

Microsoft ऐसे परिवर्तन कर सकता है जो .NET Core में टूट रहे हैं जो 4.5 पर प्रभाव नहीं डालते हैं। मुझे संदेह है कि वे ADO.NET जैसे निम्न स्तर पर 1.0 RTM पोस्ट करेंगे, लेकिन बार कम है। यह विंडोज का हिस्सा नहीं है और .NET कोर संस्करणों को साथ-साथ तैनात किया जा सकता है।

सार वर्ग बदला जा सकता है - वह तोड़ नहीं रहा है। बस एक ऐसी विधि जोड़ें जो डिफ़ॉल्ट कार्यान्वयन के साथ आभासी हो। यह पहले से ही ADO.NET async विधियों के साथ किया जा चुका है। .NET कोर की शुरूआत के साथ मेरा मानना ​​है कि साझा कक्षाओं में परिवर्तन संगतता बनाए रखने के लिए .NET 4.5 रिलीज के साथ मिलकर किए जाने की आवश्यकता होगी। अगर कोई गलत है तो मुझे सही करें और केवल इंटरफेस पर लागू होता है: मुस्कराहट:

@FransBouma

कोई भी आधिकारिक प्रदाता ऐसा नहीं करता है कि SqlClient को छोड़कर, अन्य सभी, जैसे ODP.NET, async कोड के किसी भी रूप को लागू नहीं करते हैं और इस प्रकार कॉलिंग कोड सिंक वेरिएंट पर वापस आ जाता है

आप सही हैं, लेकिन यह एपीआई के साथ कोई समस्या नहीं है, और कार्यान्वयनकर्ताओं द्वारा अधिक आलस्य या समझ की कमी है। उदाहरण के लिए MySql कनेक्टर ने अपने सभी async तरीकों को एक TaskCompletionSource बनाकर और उन्हें सिंक विधियों के साथ पूरा करके फिर से लागू किया, जो कि हास्यास्पद है। वे अपने कोड बेस का आधा हिस्सा ही हटा सकते हैं और उसी व्यवहार के साथ बने रह सकते हैं।

यह नहीं कह रहा है कि इंटरफेस इसे हल करेंगे, लेकिन एसिंक के लिए डिफ़ॉल्ट व्यवहार नहीं होने से कम से कम उनमें से कुछ इसके बारे में सोचेंगे। तथ्य यह है कि 90% बहुत तकनीकी लोग एसिंक ऑपरेशंस को नहीं समझते हैं, इससे भी मदद नहीं मिलती है।

सार वर्ग बदला जा सकता है - वह तोड़ नहीं रहा है। बस एक ऐसी विधि जोड़ें जो डिफ़ॉल्ट कार्यान्वयन के साथ आभासी हो। यह पहले से ही ADO.NET async विधियों के साथ किया जा चुका है।

यह टूट रहा है। यह उन सभी पुस्तकालयों के लिए तोड़ रहा है जिन्होंने इस कार्यान्वयन को उप-वर्गीकृत किए बिना इसे जोड़ा गया था और लोग इस सोच का उपभोग करते हैं। ओह यह कार्यान्वयन अब postgresql BAM ERROR wtf के साथ समर्थित है ...

एक डीबी अबास्ट्रक्शन के लिए जबरन कार्यान्वयन गलत है।

इससे कोई फर्क नहीं पड़ता कि इसका इंटरफेस या बेस क्लास है या नहीं। ब्रेकिंग परिवर्तन होंगे। लेकिन जबरन पूर्वनिर्धारित कार्यान्वयन गलत है।

बहुरूपता उस तरह से काम नहीं करता है। आप किसी विधि को जाने बिना उसे ओवरराइड नहीं कर सकते। यदि आपका संदर्भ एक डीबीकनेक्शन है और आप QueryAsync को कॉल करते हैं, तो यह केवल उस विधि को कॉल करेगा या जिसे इसे ओवरराइड किया गया है। एक उपवर्ग में पहले से मौजूद QueryAsync नामक एक विधि को नहीं कहा जाएगा।

आप एक विधि छंद को उसी नाम से छिपाने में भ्रमित कर रहे हैं।

@जेम्सएनके

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

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

तो, अमूर्त वर्ग जहां कार्यान्वयन मौजूद हो सकता है जो उप वर्ग से संबंधित नहीं है। या इंटरफेस जहां तीसरे पक्ष के लिए कोई डिफ़ॉल्ट कार्यान्वयन मौजूद नहीं है।

@ फिलिप-हेडन इसलिए इसे एक आभासी विधि के रूप में लागू किया गया है, न कि एक अमूर्त विधि के रूप में।

आप सामान जोड़ सकते हैं यह केवल उपवर्गों को तोड़ देगा जिनके पास पहले से ही एक ही हस्ताक्षर (नाम/तर्क) वाला सदस्य है। यदि तर्क अलग हैं तो डेवलपर्स ओवरलोड को गलती करते हैं तो यह सूक्ष्म बग पेश कर सकता है।

वह मजबूर कार्यान्वयन है जो उप वर्ग से संबंधित नहीं है।

फिर वहां मत डालो।

@jamesnk

इसे वहां मत डालो। इसलिए हम इंटरफेस को हटाने का तर्क दे रहे हैं।

इसे वर्चुअल बनाने से समस्या का समाधान नहीं होता है। कोई पूर्व परिभाषित कार्यान्वयन नहीं होना चाहिए। कहानी का अंत

@JamesNK इस मामले में हमने इसे वहां नहीं रखा, _Microsoft_ ने इसे सार में शामिल करके वहां रखा। _all_ प्रदाताओं में काम करने के लिए मानी जाने वाली विधियों को जोड़ना जो कभी भी विरासत में मिला है, मैं वास्तव में कुशलता से सुचारू रूप से नहीं जा रहा हूं, भले ही तकनीकी रूप से टूट न जाए (मैं "नए का उपयोग करना चाहिए" संकलन चेतावनियों को स्वीकार करूंगा _तकनीकी रूप से_ तोड़ नहीं रहे हैं)। _most_ मामलों में कोई साझा या तुरंत साझा कार्यान्वयन नहीं होगा। तो विकल्प क्या है? throw new NotImplementedException() उस वर्चुअल के अंदर? इसके लिए शायद ही कोई तर्क पहले से मौजूद है, यह अधिक (रनटाइम) समस्याओं से भरा है।

आइए आज देखें: जब कोई प्रदाता इसका समर्थन करता है, तो मैं इसके बजाय एक IDbAsyncConnection जोड़ूंगा, न कि कवर के नीचे समकालिक तरीकों के समूह के बजाय जो भ्रम और अक्षमता की ओर ले जाता है,

मैं इसके बजाय एक IDbAsyncConnection को देखना चाहता हूं, जब कोई प्रदाता इसका समर्थन करता है, न कि उन तरीकों के एक समूह के बजाय जो कवर के तहत समकालिक होते हैं जिससे भ्रम और अक्षमता होती है

@NickCraver +1000 उस पर। इस बग की तरह यहाँ जहाँ oracle टीम को समझ में नहीं आता कि async का क्या अर्थ है।

आप इंटरफेस के साथ ऐसा कर सकते हैं। उनके साथ समस्या यह है कि आप उन तर्कों को स्वीकार नहीं कर सकते जो एकाधिक इंटरफेस की मांग करते हैं, उदाहरण के लिए मुझे एक प्रकार की आवश्यकता है जो IDbAsyncConnection और IDbConnection दोनों है। आप मजबूत टाइपिंग खो देते हैं और आपको इंटरफेस COM शैली के लिए पूछताछ शुरू करनी होगी जो मुझे नहीं लगता कि यह बहुत उपयोगकर्ता के अनुकूल है। यह एपीआई डिज़ाइन में एक उपकरण है जिसमें इसकी जगह है लेकिन मुझे नहीं पता कि मैं डिफ़ॉल्ट रूप से इसमें जाऊंगा या नहीं।

यदि डिफ़ॉल्ट कार्यान्वयन NotImplementedException फेंक रहा था तो इसे बेस क्लास पर बोल्ट करना गलत काम है। जैसा मैंने कहा, इसे वहां मत डालो। अगर आप किसी को ऐसा करते देखते हैं तो एक मुद्दा उठाएं।

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

@JamesNK संभावित रूप से IDbAsyncConnection IDbConnection का उत्तराधिकारी होगा, लेकिन जरूरी नहीं कि ऐसा ही हो - वे आम सदस्यों को साझा कर सकते हैं या एक सामान्य आधार से प्राप्त कर सकते हैं। उदाहरण के लिए डैपर में हम शायद इस प्रकार लागू करेंगे:

``` सी#
IEnumerableजिज्ञासा(यह आईडीबीकनेक्शन सीएनएन, कमांडडिफिनिशन सीएमडी)

``` C#
Task<IEnumerable<T>> QueryAsync<T>(this IDbAsyncConnection cnn, CommandDefinition cmd)

मुझे लगता है कि सिंक/एसिंक विधियों वाले अधिकांश पुस्तकालयों में समान उपयोग और कार्यान्वयन होंगे।

_संपादित करें:_ टाइप करने के बाद मुझे एहसास हुआ कि नाम के अंत में Async इन सभी के लिए कितना बेहतर होगा...

पिछले कुछ वर्षों में ADO.NET में निम्नलिखित बड़े परिवर्तन हुए:

1. 2003 (1.1) को उन्होंने 1.0 से एक ब्रेकिंग बदलाव किया और इसे फिर से डिजाइन किया
2. २००५ (२.०) को वे प्रदाता मॉडल में चले गए, जिसमें आज मौजूद आधार वर्ग हैं
3. २०१२ (४.५) पर ​​उन्होंने एसिंक सपोर्ट जोड़ा, जो वास्तव में नए तरीकों को जोड़ने के अलावा कुछ भी नहीं बदला जो समान चीजों को अतुल्यकालिक रूप से करते थे।

जिस तरह से 2003 एपीआई को परिभाषित किया गया था, उस पर वापस जाना एक बदलाव है जो या तो संगतता को तोड़ देगा (जो लोग नहीं चाहते हैं) या पिछले दशक में जोड़े गए सुविधाओं को हटा दें। लेकिन वर्तमान डिज़ाइन के साथ .NET कोर में एक नया इंटरफ़ेस जोड़ना किसी भी .NET संस्करण के साथ _source संगत_ है। पिछले 15 वर्षों में लिखे गए अधिकांश कोड को काम करने के लिए आपको केवल पुन: संकलन की आवश्यकता है। और कोरएफएक्स को लक्षित करने के लिए आपको वैसे भी पुन: संकलित करने की आवश्यकता होगी।

यह एपीआई लंबे समय से स्थिर है। अगर लोग चाहें तो इसे इंटरफेस के रूप में फिर से डिजाइन किया जा सकता है। हमेशा की तरह, यहां कोई तकनीकी समस्या नहीं है, यह निशान, वरीयताओं और अहंकार तक उबाल जाता है।

इंटरफेस को वापस क्यों न लाएं और उन्हें अप्रचलित चिह्नित करें?

हालांकि इस विचार को छोड़ दिया गया था, मैं सोच रहा हूं कि क्या इस तरह की स्थिति में असेंबली न्यूट्रल इन्फेरफेस मदद कर सकते हैं, इसे देखें http://davidfowl.com/assembly-neutral-interfaces/ और फिर उनका कार्यान्वयन
http://davidfowl.com/assembly-neutral-interfaces-implementation/

मुझे लगता है कि असेंबली तटस्थ इंटरफेस यहां एक लाल हेरिंग हैं; अगर कुछ है
होने के लिए, यह पूरी तरह से एक "सामान्य" बात है, क्योंकि "सामान्य" मौजूद है। इसके अलावा
फीचर के वाष्पित होने के बाद से मूक है।
28 नवंबर 2015 को शाम 5:38 बजे, "शाहिद खान" नोटिफिकेशन @github.com ने लिखा:

हालांकि इस विचार को छोड़ दिया गया था, मैं सोच रहा हूं कि क्या विधानसभा तटस्थ है
इस तरह की स्थिति में अनुमान लगाने वाले मदद कर सकते थे इसे देखें
http://davidfowl.com/assembly-neutral-interfaces/ और फिर उनके
कार्यान्वयन
http://davidfowl.com/assembly-neutral-interfaces-implementation/

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/dotnet/corefx/issues/3480#issuecomment -160323344।

मैं क्या देखता हूं:

• CoreClr (नया चमकदार ढांचा) के विचार के पीछे के लोग इसके कार्यान्वयन के पीछे के लोगों से पूरी तरह से अलग हैं (15 साल पुराने कोडबेस के साथ पिछड़ा संगतता राजा है)।

क्या मुझे लगता है कि:

• इंटरफेस को हटाकर आप चीजों को और खराब कर रहे हैं।
• [अप्रचलित] से सजाए जाने तक कुछ भी अप्रचलित नहीं है। और इससे कोई फर्क नहीं पड़ता कि कौन किसी भी समय क्या सोचता है। यह अनुबंध है और यदि आप इसे संतुष्ट नहीं कर रहे हैं तो आप नहीं हैं।

जो मैं चाहता हूं:

• बेस क्लास (एस) के बजाय एपीआई की आधार सतह के रूप में इंटरफेस का प्रयोग करें।

मैं जो महसूस करता हूं:

• हम 2015 के अंत में हैं और लोगों को इस पर बहस करते हुए देखना निराशाजनक और दुखद है।

इंटरफेस को वर्जन नहीं किया जा सकता है।

निश्चित रूप से इंटरफेस को इंटरफेस विरासत के साथ आसानी से संस्करणित किया जा सकता है? और अगर यह कुछ बिल्कुल अलग कर रहा है; अच्छा यह एक अलग इंटरफ़ेस है।

interface IOldInterface {}
interface INewInterface : IOldInterface {}
interface IDifferentInterface {}

class SomeClass : IOldInterface, INewInterface, IDifferentInterface
{
}

बस इसे IInterfaceV2 , IInterfaceV3 न कहें, इसे यह समझाने की जरूरत है कि यह क्या जोड़ता है।

पुराने इंटरफ़ेस [Obsolete] को संदर्भ में रखने के लिए, और कुछ नए इंटरफ़ेस का उपयोग करें और उन्हें कॉल करें कि वे वास्तव में क्या हैं; इस दिन और उम्र में सामान्य लगने वाली गैर-एसिंक विधियों के बजाय।

public interface IDbUtilityProviderFactory 
{
    IDbConnectionStringBuilder CreateConnectionStringBuilder();
    IDbParameter CreateParameter();
}

public interface IDbBlockingProviderFactory : IDbUtilityProviderFactory 
{
    IDbBlockingCommand CreateBlockingCommand();
    IDbBlockingConnection CreateBlockingConnection();
}

public interface IDbAyncProviderFactory : IDbUtilityProviderFactory 
{
    IDbCommandAsync CreateAsyncCommand();
    IDbConnectionAsync CreateAsyncConnection();
}

@abatishchev

CoreClr (नया चमकदार ढांचा) के विचार के पीछे के लोग इसके कार्यान्वयन के पीछे के लोगों से पूरी तरह से अलग हैं (15 साल पुराने कोडबेस के साथ पिछड़ा संगतता राजा है)।

इसे स्पष्ट करने के लिए धन्यवाद, ऐसा लगता है कि इसे इंगित करने की आवश्यकता है। आम तौर पर मेरा मानना ​​​​है कि एमएस टीमें पिछड़ी संगतता के बारे में गहराई से ध्यान रखती हैं जो दोनों भाषाओं और उनके प्लेटफॉर्म को विकसित करने के लिए महत्वपूर्ण है। यह सिर्फ इतना है कि System.Data के आसपास के निर्णय व्यापक पारिस्थितिकी तंत्र को ध्यान में रखते हुए नहीं किए जा रहे हैं - जो कि इन मूल सारों को समान रूप से परोसना चाहिए।

• इंटरफेस को हटाकर आप चीजों को और खराब कर रहे हैं।
• [अप्रचलित] से सजाए जाने तक कुछ भी अप्रचलित नहीं है। और इससे कोई फर्क नहीं पड़ता कि कौन किसी भी समय क्या सोचता है। यह अनुबंध है और यदि आप इसे संतुष्ट नहीं कर रहे हैं तो आप नहीं हैं।

सटीक रूप से।

इंटरफेस वर्जनिंग के संबंध में। अगर मैं गलत हूं तो मुझे सुधारें लेकिन मैंने सोचा कि CoreClr की बात अधिक बारीक, स्वतंत्र संस्करण है? ब्रेकिंग चेंज? बूम! नया प्रमुख संस्करण जारी किया गया।
ऐसा लगता है कि 15 साल के डिजाइन अनुभव के बाद, आप वही गलतियों को दोहराने जा रहे हैं, लेकिन अब स्वतंत्र रूप से संस्करणित और नगेट पैकेज जारी किए गए हैं। ऊपर दिए गए तर्क अच्छे पुराने अखंड ढांचे के समान हैं, इसके बावजूद अब यह नहीं है।
यदि पिछड़ी संगतता आपके लिए जरूरी है तो आप उन इंटरफेस को हटा नहीं सकते हैं। यदि ऐसा नहीं है तो आइए इसके बारे में बात करना बंद करें और एपीआई को खरोंच से डिजाइन करें, इस बार प्रमुख ओआरएम लेखकों और अन्य ADO.NET अनुभवी डेवलपर्स को सुनें।
धन्यवाद।

@abatishchev बहुत अच्छे अंक। आश्चर्य है कि मैं भी: पश्चगामी संगतता तर्क का वास्तव में क्या मतलब है? यदि CoreClr में कोई नई सुविधा जोड़ी जाती है, तो इसका उपयोग करने वाली हर चीज़ .net full पर नहीं चलेगी, इसलिए सुरक्षित रहने के लिए केवल सामान्य व्यवहार का ही उपयोग किया जा सकता है। (जिसने कभी अच्छा काम नहीं किया)।

मेरी ओर से लंबी चुप्पी के लिए खेद है।

.NET कोर में पोर्ट करना

सबसे पहले, चलो कमरे में हाथी के बारे में बात करते हैं, जो कि .NET कोर में लगभग उतने एपीआई उपलब्ध नहीं हैं जितने लोग - हमारे सहित - की उम्मीद करेंगे।

मैं अपनी टीम के साथ दस्तावेज़ों का एक सेट तैयार करने के लिए काम कर रहा हूं कि हम मौजूदा संपत्तियों को .NET कोर में पोर्ट करने के क्षेत्र में कैसे पहुंचेंगे।

हम अधिक कार्यक्षमता को पोर्ट करने की योजना बना रहे हैं जो वर्तमान में केवल .NET फ्रेमवर्क / मोनो में .NET कोर में मौजूद है। यह दस्तावेज़ बताएगा कि हम इसे कैसे करने जा रहे हैं, हम कैसे प्राथमिकता देते हैं, और यांत्रिकी क्या होगी। न केवल मैं चाहता हूं कि वह काम खुले में हो, मैं समुदाय को और अधिक कार्यक्षमता पोर्ट करने में मदद करने में सक्षम बनाना चाहता हूं।

ब्रेकिंग चेंज

जब लोग .NET Core के बारे में बात करते हैं तो एक क्षेत्र बहुत भ्रम पैदा करता है। एक बात स्पष्ट कर दूं:

यदि .NET Core में .NET Framework की तुलना में कम API हैं तो यह एक महत्वपूर्ण परिवर्तन नहीं है।

इसका कारण यह है कि .NET Core एक नया प्लेटफॉर्म है और इसमें तकनीकी रूप से एपीआई का एक मनमाना सेट हो सकता है। हालाँकि, निश्चित रूप से, हम एक मनमाना सेट नहीं चाहते हैं - यही हमने अतीत में किया है। .NET कोर के लिए लक्ष्य एक ऐसी कहानी बनाना है जहां लोग पुस्तकालयों को लेखक बना सकें (और कंसोल ऐप्स के साथ एक निश्चित विस्तार वाले ऐप्स भी) जो .NET फ्रेमवर्क और .NET कोर पर चलेंगे। इसके लिए आवश्यक है कि दोनों प्लेटफार्मों का एक सबसेट हो जो 100% संगत हो। उस संदर्भ में, आप हमें परिवर्तनों को तोड़ने के बारे में बात करते हुए सुनेंगे।

उसके ऊपर, हमारा इरादा .NET कोर के भीतर एक उच्च संगत बार रखना है। दूसरे शब्दों में, हम .NET कोर एपीआई के एक संस्करण और दूसरे के बीच एपीआई ब्रेकिंग परिवर्तन करने की योजना नहीं बनाते हैं।

इंटरफेस

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

WinRT, जो COM पर आधारित है और इस प्रकार इंटरफेस पर बहुत अधिक निर्भर करता है, अधिक इंटरफेस बनाकर इस समस्या को हल करता है, जैसे IFoo , IFoo2 , IFoo3 । यह करने योग्य है, लेकिन इसे सहने योग्य बनाने के लिए रनटाइम या भाषा सुविधा के बिना यह निश्चित रूप से गड़बड़ है। अभी तक, ऐसी सुविधा मौजूद नहीं है। हालांकि, भाषा डिजाइन टीम के सदस्य के रूप में मुझे प्रस्ताव सुनने में काफी दिलचस्पी है। अन्य भाषाओं और प्लेटफार्मों में उस स्थान में संबंधित विचार हैं, और मैं सक्रिय रूप से विकल्पों में भी देख रहा हूं (जैसे मिश्रण-इन/लक्षण, स्विफ्ट का विस्तार-सब कुछ, या इंटरफेस के लिए डिफ़ॉल्ट सदस्य)।

चूंकि हम अभी भी पश्चगामी संगतता की परवाह करते हैं, इसलिए हम आम तौर पर इंटरफेस पर सार आधार प्रकारों का पक्ष लेते हैं।

ADO.NET इंटरफेस

यह सब कहा जा रहा है, आइए इस सूत्र में मूल प्रश्न के बारे में बात करें: ADO.NET प्रदाता इंटरफेस को उजागर करना।

जैसा कि डेविड ने समझाया: जब अमूर्त आधार प्रकार पेश किए गए थे, तो हमने इन्हें बहिष्कृत माना था, जो कि .NET 2 / Visual Studio 2005 में था। ऐसा लगता है कि इन इंटरफेस का होना ORM फ्रेमवर्क को .NET कोर में पोर्ट करने के लिए महत्वपूर्ण है। मेरे लिए, यह पर्याप्त सबूत प्रदान करता है कि हमें इंटरफेस को .NET कोर में पोर्ट करना चाहिए।

हालाँकि, जैसा कि सभी नए एपीआई के साथ होता है, हमें .NET कोर के प्राथमिक लक्ष्यों में से एक के प्रति सचेत रहने की आवश्यकता है, जिसमें एक घटक स्टैक है। इंटरफ़ेस IDataReader की निर्भरता DataTable , जिसकी निर्भरता DataSet । जैसा कि dotnet/runtime#14302 में बताया गया है, हम DataTable लिए समर्थन जोड़ने का विरोध नहीं कर रहे हैं, लेकिन हम DataSet विरासत पर विचार करते हैं। हालाँकि, हम अभी भी इसे एक अलग पैकेज के रूप में जोड़ सकते हैं, लेकिन किसी भी तरह से इसके लिए इंटरफेस से निर्भरता श्रृंखला को तोड़ने की आवश्यकता होगी -> DataTable -> DataSet । हम वहां क्या कर सकते हैं, यह देखने के लिए मैं @YoungGah के साथ काम

क्या यह दृष्टिकोण चिंताओं को दूर करेगा?

जब तक मैं गलत नहीं हूँ, IDataReader में केवल DataTable निर्भरता है
GetSchemaTable() विधि, पहले से ही DataTable में विस्तार से चर्चा की गई है
जंजीर। हालांकि, मैं तुरंत स्वीकार करता हूं कि तथ्य यह है कि एक है
बाद की तारीख में समान कार्यक्षमता के _some_ दिमाग को जोड़ने की उम्मीद है (चाहे
डेटाटेबल के माध्यम से या नहीं) इसे इस पर बेनकाब करना बहुत अजीब बनाता है
इंटरफ़ेस, क्योंकि बाद में इंटरफ़ेस का विस्तार करना समस्याग्रस्त है। यह नहीं होगा
"अभी के लिए विधि हटाएं, बाद में कुछ और जोड़ें" जितना सरल
5 दिसंबर 2015 को 12:17 बजे, "इमो लैंडवर्थ" नोटिफिकेशन @github.com ने लिखा:

मेरी ओर से लंबी चुप्पी के लिए खेद है।
.NET कोर में पोर्ट करना

सबसे पहले, कमरे में हाथी के बारे में बात करते हैं, जो कि .NET . है
कोर में लगभग उतने एपीआई उपलब्ध नहीं हैं जितने लोग - जिनमें शामिल हैं
हम - उम्मीद करेंगे।

हम कैसे आगे बढ़ रहे हैं, इस पर दस्तावेज़ों का एक सेट तैयार करने के लिए मैं अपनी टीम के साथ काम कर रहा हूं
मौजूदा परिसंपत्तियों को .NET कोर में पोर्ट करने के क्षेत्र में संपर्क करने के लिए।

हम अधिक कार्यक्षमता को पोर्ट करने की योजना बना रहे हैं जो वर्तमान में केवल
.NET फ्रेमवर्क / मोनो से .NET कोर में मौजूद है। यह दस्तावेज़ बाहर बुलाएगा
हम यह कैसे करने जा रहे हैं, हम कैसे प्राथमिकता देते हैं, और यांत्रिकी क्या करेंगे
होना। मैं चाहता हूं कि वह काम न केवल खुले में हो, बल्कि मैं यह भी चाहता हूं
समुदाय को सक्षम करें हमें अधिक कार्यक्षमता पोर्ट करने में मदद करें।
ब्रेकिंग चेंज

एक ऐसा क्षेत्र है जिसके बारे में जब लोग बात करते हैं तो बहुत भ्रम होता है
.NET कोर। एक बात स्पष्ट कर दूं:

यदि .NET Core में .NET की तुलना में कम API हैं तो यह एक महत्वपूर्ण परिवर्तन नहीं है
ढांचा।

इसका कारण यह है कि .NET Core एक नया प्लेटफॉर्म है और यह तकनीकी रूप से हो सकता है
एपीआई का एक मनमाना सेट है। हालाँकि, निश्चित रूप से, हम नहीं चाहते हैं
मनमाना सेट
http://blogs.msdn.com/b/dotnet/archive/2014/12/04/introducing-net-core.aspx
- यही हमने अतीत में किया था। .NET कोर के लिए लक्ष्य है a
कहानी जहां लोग पुस्तकालयों को लेखक बना सकते हैं (और कंसोल ऐप्स के साथ एक निश्चित
एक्सटेंड इवन एप्स) जो .NET फ्रेमवर्क और .NET कोर पर चलेंगे। इस
आवश्यकता है कि दोनों प्लेटफार्मों का एक सबसेट हो जो कि १००% है
अनुकूल। उस संदर्भ में, आप हमें परिवर्तनों को तोड़ने के बारे में बात करते हुए सुनेंगे।

उसके ऊपर, हमारा इरादा .NET कोर के भीतर एक उच्च संगत बार रखना है।
दूसरे शब्दों में, हम बीच में एपीआई ब्रेकिंग परिवर्तन करने की योजना नहीं बनाते हैं
एक .NET Core API का एक संस्करण और दूसरा।
इंटरफेस

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

WinRT, जो COM पर आधारित है और इस प्रकार इंटरफेस पर बहुत अधिक निर्भर करता है,
IFoo, IFoo2, जैसे अधिक इंटरफेस बनाकर इस समस्या को हल करता है।
आईफू3. यह करने योग्य है, लेकिन रनटाइम के बिना यह निश्चित रूप से गन्दा है या
इसे सहने योग्य बनाने के लिए भाषा सुविधा। अभी तक, ऐसी सुविधा मौजूद नहीं है।
हालांकि, भाषा डिजाइन टीम के एक सदस्य के रूप में मुझे इसमें काफी दिलचस्पी है
प्रस्तावों को सुनें। अन्य भाषाओं और प्लेटफार्मों में संबंधित विचार हैं
अंतरिक्ष, और मैं सक्रिय रूप से विकल्पों में भी देख रहा हूं (जैसे
मिश्रण-इन/लक्षण, स्विफ्ट का विस्तार-सब कुछ, या के लिए डिफ़ॉल्ट सदस्य
इंटरफेस)।

चूंकि हम अभी भी पश्चगामी संगतता की परवाह करते हैं, इसलिए हम आम तौर पर इसके पक्ष में हैं
इंटरफेस पर सार आधार प्रकार।
ADO.NET इंटरफेस

यह सब कहा जा रहा है, आइए इस सूत्र में मूल प्रश्न के बारे में बात करते हैं:
ADO.NET प्रदाता इंटरफेस को उजागर करना।

जैसा कि डेविड ने समझाया: हमने अमूर्त आधार होने पर इन्हें पदावनत माना
प्रकार पेश किए गए, जो .NET 2 / Visual Studio 2005 में थे। ऐसा लगता है
यह दृढ़ विश्वास है कि इन इंटरफेस का होना महत्वपूर्ण है
पोर्ट ORM चौखटे .NET कोर के लिए। मेरे लिए, यह पर्याप्त सबूत प्रदान करता है
कि हमें इंटरफेस को .NET Core में पोर्ट करना चाहिए।

हालाँकि, जैसा कि सभी नए एपीआई के साथ होता है, हमें इनमें से किसी एक पर ध्यान देने की आवश्यकता है
.NET कोर के प्राथमिक लक्ष्य, जिसमें एक कंपोनेंटाइज्ड स्टैक है। NS
इंटरफ़ेस IDataReader की डेटाटेबल पर निर्भरता है, जिसमें a
डेटासेट पर निर्भरता। जैसा कि डॉटनेट/रनटाइम#14302 . में उल्लिखित है
https://github.com/dotnet/corefx/issues/1039 , हम जोड़ने के विरोध में नहीं हैं
डेटाटेबल के लिए समर्थन, लेकिन हम वास्तव में डेटासेट को पोर्ट नहीं करना चाहते हैं। इसलिए
इंटरफेस जोड़ने के लिए उस निर्भरता को तोड़ने की आवश्यकता होगी। मैं साथ काम करूंगा
@YoungGah https://github.com/YoungGah के साथ यह देखने के लिए कि हम वहां क्या कर सकते हैं।

क्या यह दृष्टिकोण चिंताओं को दूर करेगा?

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/dotnet/corefx/issues/3480#issuecomment -162115855।

हां, IDataReader की DataTable पर निर्भरता है जिसकी डेटासेट पर निर्भरता है।

जैसा कि पहले उल्लेख किया गया है, हम सदस्यों को इंटरफेस से नहीं हटा सकते हैं, इसलिए हमें उस निर्भरता को किसी अन्य तरीके से तोड़ने की आवश्यकता होगी; या तो इंटरफ़ेस को पोर्ट न करके, या डेटाटेबल -> डेटासेट निर्भरता को तोड़कर।

क्या यह दृष्टिकोण चिंताओं को दूर करेगा?

हाँ GetSchemaTable() विधि के बिना भी ADO.NET इंटरफेस को पुनर्स्थापित करना ADO.NET इंटरफ़ेस मुद्दों पर भारी निर्भरता को हल करेगा जिसका मैं वर्तमान में सामना कर रहा हूं।

मैं डेटाटेबल को तोड़ रहा हूं -> डेटासेट निर्भरता अगर इसका मतलब GetSchemaTable() भी शामिल होगा, तो GetSchemaTable() पर निर्भर लोगों के लिए पसंदीदा तरीका होगा (ताकि मेरा वोट हो) - लेकिन मैं उन देवों को अधिक भार दूंगा जो इससे प्रभावित होते हैं।

@terrajobst आपके सारांश और अपने विचार साझा करने के लिए धन्यवाद।

@terrajobst सारांश और स्पष्टीकरण के लिए धन्यवाद। मैं Npgsql को बनाए रखता हूं इसलिए ADO.NET प्रदाता के दृष्टिकोण से लिख रहा हूं, ORM से नहीं।

ऐसा लगता है कि .NET कोर में, Microsoft को ADO.NET की कुछ लंबे समय से चली आ रही विरासती विशेषताओं, अर्थात् डेटाटेबल/डेटासेट और इंटरफेस को हटाने की इच्छा थी। यह आगे बढ़ने के लिए एक बेहतर, क्लीनर एपीआई बनाता है, लेकिन पहले से ही इंटरफेस और डेटाटेबल/डेटासेट एपीआई के आधार पर उपयोगकर्ताओं के लिए पर्याप्त काम करता है।

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

यहां एक अतिरिक्त निराशाजनक कारक यह है कि ADO.NET इंटरफेस रखने का अर्थ डेटाटेबल/डेटासेट को भी रखना है। दूसरे शब्दों में, हालांकि मैं व्यक्तिगत रूप से इंटरफेस समस्या के बारे में बहुत दृढ़ता से महसूस नहीं करता हूं, उन्हें रखने का मतलब डेटाटेबल/डेटासेट रखना है और यह अधिक समस्याग्रस्त लगता है।

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

PS आप जो कुछ भी करते हैं, इंटरफ़ेस विस्फोट के मार्ग से नीचे न जाएं, अर्थात IFoo2, IFoo3। यह सिर्फ एक गैर-समाधान है।
पीपीएस यदि आप .NET कोर में एक नया गैर-डेटाटेबल मेटाडेटा एपीआई बनाने का निर्णय लेते हैं और चाहते हैं कि .NET कोर लाइब्रेरी .NET फ्रेमवर्क में चले, तो इसका मतलब है कि आपको नए एपीआई के साथ एक नया .NET फ्रेमवर्क जारी करना होगा। .NET कोर।

@terrajobst चुप्पी तोड़ने के लिए धन्यवाद;)। मुझे लगता है कि मूल मुद्दा यह है कि ADO.NET के लिए कोई डिज़ाइन मौजूद नहीं है। कुछ समय के लिए नहीं रहा है और यह एपीआई के विभिन्न हिस्सों में दिखाता है जो कुछ मिनटों से अधिक समय तक चीजों को सोचने के बिना सुविधाओं पर गद्देदार है (ऐसा लगता है)। मैं इस पर @roji से सहमत हूं: .NET कोर जीवन में एक बार चीजों के बारे में कुछ करने का मौका है, इसलिए .NET कोर को (मेरी राय में, मूर्खतापूर्ण) नियम से पीछे नहीं हटना चाहिए कि यह पीछे की ओर संगत होना चाहिए .NET पूर्ण।

उस ने कहा, अगर ADO.NET के लिए चीजें बेहतर नहीं हो रही हैं (यानी इसे एक वास्तविक डिज़ाइन मिलता है जहां एक सामान्य एपीआई डिज़ाइन किया जाता है जिसे एसक्ल क्लाइंट में विशिष्ट किया जाता है और दूसरी तरफ नहीं! तो सुविधाएं उपलब्ध नहीं हैं SQL सर्वर लेकिन अन्य डेटाबेस में सामान्य API में जोड़े जाते हैं और ADO.NET प्रदाता लेखक के लिए नहीं छोड़े जाते हैं), तो अगली सबसे अच्छी बात यह है कि इंटरफेस सहित जितना संभव हो उतना अधिक पोर्ट करना और हम तृतीय पक्ष देव #ifdef स्वयं गड्ढों के आसपास जो छोड़े जाएंगे।

हालाँकि, डेटाटेबल निर्भरता एक समस्या हो सकती है, क्योंकि IDataReader इंटरफ़ेस चीजों को .NET पूर्ण _if_ डेटाटेबल के साथ पीछे की ओर संगत रखना कठिन बना देगा, चाहे किसी भी रूप में पोर्ट न किया गया हो। लेकिन मुझे लगता है कि वैसे भी यह एक खोया हुआ कारण है। एमएस द्वारा कई बार कहा गया था कि .NET पूर्ण को .NET कोर के रूप में कई / बार-बार अपडेट प्राप्त नहीं होंगे, इसलिए यदि .NET कोर में कुछ _new_ जोड़ा जाता है, तो कोई भी इसका उपयोग नहीं कर सकता है, क्योंकि इसका उपयोग करने से पुस्तकालय बनता है .NET पूर्ण के साथ तुरंत असंगत। मुझे यहां कुछ याद आ रहा है, इसलिए यदि ऐसा है, तो कृपया मुझे सुधारें :)

यह अकेले ही इसे एक अजीब स्थिति बनाता है: पीछे की ओर संगतता होनी चाहिए, लेकिन व्यवहार में इसे हासिल करना कठिन लगता है और वैसे भी एक लाल हेरिंग। IMHO अगर इसे पहले संबोधित किया गया है, तो इसके परिणाम का उपयोग .NET कोर के एपीआई के साथ क्या करना है, इस पर उचित निर्णय लेने के लिए किया जा सकता है, यानी पुराने खराब तरीके से डिजाइन किए गए क्रॉफ्ट को .NET से पूर्ण रूप से खींचने के बजाय उन्हें सुधारें। यह कहना नहीं है कि सभी एपीआई बुरी तरह से डिजाइन किए गए हैं, हालांकि ADO.NET (जैसा कि मैंने पहले की पोस्ट में वर्णित किया है) के साथ, चीजें कई सालों से ठीक से नहीं की गई हैं। एक साफ ब्रेक बनाना और इसके बजाय एक प्रणाली को लागू करना जो अधिक मजबूत हो सकता है (जेडीबीसी अभी भी मजबूत हो रहा है, ओडीबीसी अभी भी 25 साल पहले की तरह काम करता है) और परिवर्तन के लिए अनुकूली बेहतर है।

इस बारे में थोड़ा और सोचने पर, @FransBouma की पश्चगामी संगतता आवश्यकता पर टिप्पणी बहुत मायने

मैं समझता हूं कि पश्चगामी संगतता एक आवश्यकता है जो इस ADO.NET-विशिष्ट चर्चा से बहुत आगे जाती है, मैं बस सोच रहा हूं।

यह @roji के आसपास का दूसरा तरीका है: एपीआई को न तोड़कर लघु पुनरावृत्तियों को सक्षम किया जाता है।

यदि आप एक .Net डेवलपर हैं और आपका बिल्ड हर हफ्ते टूटता रहता है क्योंकि अंतर्निहित ढांचे का एपीआई लगातार बदल रहा है तो आपको किसी अन्य प्लेटफॉर्म पर विचार करने में ज्यादा समय नहीं लगेगा।

तो यह गैर-ब्रेकिंग परिवर्तनों द्वारा संचालित तेज़ पुनरावृत्ति है।

(संपादित)
आप केवल तब तक परिवर्तनों को तोड़े बिना पुनरावृति कर सकते हैं जब तक कि आपको किसी वर्ग इंटरफ़ेस में कुछ जोड़ना, व्यवहार परिवर्तन (!) .net कोर आपके कोड को .net पूर्ण के साथ संगत नहीं बनाएगा, इसलिए इस अर्थ में यह .net कोर को .net पूर्ण के साथ अब पीछे की ओर संगत नहीं बना देगा _ कोड के उस टुकड़े के लिए_। कौन सा आईएमएचओ या तो .NET कोर के लिए नीचे आता है, हमेशा वही (वर्ग) इंटरफेस और व्यवहार होगा जैसा कि .NET पूर्ण में, अंतिम बाइट (जो आईएमएचओ अस्थिर है) या नई सुविधाएं प्राप्त करेगा जो बाद में बैकपोर्ट किए जाते हैं (जो सचमुच क्या है एमएस ने बीटीडब्ल्यू कहा) से .NET पूर्ण, प्रभावी रूप से इसे पीछे की ओर संगत नहीं बना रहा है। यह इस बात पर निर्भर करता है कि आप बाड़ के किस तरफ हैं: यदि आप कहते हैं: 'परिभाषित व्यवहार बी के साथ (वर्ग) इंटरफेस एक्स का एक सामान्य सेट है, और दोनों .NET कोर और .NET पूर्ण रूप से इन्हें लागू करते हैं और एक्स एंड बी जीता' t भविष्य में परिवर्तन', इसका अभी भी मतलब होगा कि X & B के बाहर एक नया ढांचा है जो नई चीजें प्राप्त करेगा और जो ठीक वही है जहां चीजें बदल सकती हैं और यह भी कि भविष्य कहां है।

इसके साथ कोई बहुत आगे जा सकता है, उदाहरण के लिए .NET कोर में X & B में प्रयुक्त इंटरफेस/कक्षाएं वास्तव में .NET कोर में नई कक्षाओं/इंटरफेस के चारों ओर रैपर हैं। इसके बाद यह डेवलपर पर निर्भर करता है कि वे या तो X & B का उपयोग करें या बेहतर डिज़ाइन वाले नए का उपयोग करें और .NET पूर्ण के साथ समान रूप से API के बिना।

जैसा कि हमें पहले से ही एक्स एंड बी में लापता चीजों के आसपास अपना रास्ता #ifdef करना है, दोनों ढांचे का समर्थन करते समय, आईएमएचओ .NET कोर में नए इंटरफेस/कक्षाओं को लक्षित करने में सक्षम होने के लिए बेहतर है क्योंकि जल्दी या बाद में व्यवहार में परिवर्तन होता है (शायद बहुत सूक्ष्म भी , किसी दिए गए स्थिति में एक अलग अपवाद की तरह) वैसे भी वहां क्रॉप हो जाएगा, इसलिए .NET कोर को 'पोर्टिंग' कोड इसके _new_ API (X&B नहीं) के साथ बेहतर होगा। हमें वैसे भी पोर्ट करना होगा, कम से कम मैं इसे इस तरह देखता हूं।

@ryanbnl , मैं

@roji जब तक यह फ्रेमवर्क पैकेज (जैसे जीएसी नहीं) से एक नया बाहरी है, जब यह फ्रेमवर्क और कोर दोनों के साथ संगत हो सकता है और अपने ताल पर चल सकता है; लेकिन फिर यह ओआरएम प्रदाताओं के लिए और भी अधिक परिवर्तन हो सकता है और नाम System.Data.IDbConnection पहले ही लिया जा चुका है ...

@benadams यह एक वैध टिप्पणी है - मेरे पास केवल गैर-नुगेट फ्रेमवर्क एपीआई जैसे ADO.NET दिमाग में था। हालांकि, ये चिंता का विषय होने के लिए पर्याप्त एपीआई स्थान को कवर करते प्रतीत होते हैं - .NET कोर अप्राप्य बने बिना इनमें से किसी को भी विकसित करने में सक्षम नहीं होगा (पढ़ें: इंटरफ़ेस विधियाँ या अमूर्त विधियाँ जोड़ें)

मुझे यकीन नहीं है कि आईडीबीकनेक्शन के संबंध में आपका क्या मतलब है ...

@roji का मतलब सिर्फ एक नया पैकेज था जो इस प्रकार प्रदान करता है उदाहरण के लिए System.Data.Database ; कोर और फुल दोनों के साथ संगत रहने के लिए, किसी भी प्रकार को फिर से परिभाषित नहीं किया जा सकता है जो जीएसी के पूर्ण ढांचे में होगा या यह टकराएगा।

नगेट पॉइंट पर; यह किसी भी कारण से पूर्ण और मूल दोनों के लिए नगेट में नहीं रह सका; और वर्तमान System.Data एपीआई पोस्ट 4.6.1+ को हटा दें?

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

एक पूरी तरह से नए एपीआई कि nuget में और GAC'd ढांचे के बाहर रहते थे साथ प्रयोग के लिए पीछे की ओर संगत हो सकता है netstandard1.2 जैसे 4.5.2+, coreclr, UWP, मोनो / Xamarin आदि हालांकि यह कुछ और दर्द अब हो सकता है - लेकिन यह शायद बाद की तुलना में बेहतर समय है।

यह देखते हुए कि नए एपीआई एचेमा के लिए खेल में हैं और इस तरह, DataSet को दर्शाते हुए (या DataTable ) खत्म नहीं होंगे, क्या इसे बंद कर दिया जाना चाहिए? ऐसा लगता है कि आधार वर्ग dotnet/corefx#5609 और टाइप अग्रेषण में टिप्पणियों के आधार पर आगे बढ़ने का रास्ता है, जिसका अर्थ है कि इंटरफेस का कोई उपयोग नहीं है GetSchemaTable() और कुछ अन्य उन्हें कॉम्पेट के लिए लाने के लिए नहीं हैं ... क्या यह कहना उचित है?

क्या बंद कर देना चाहिए? यदि डेटाटेबल/डेटासेट निर्भरता के कारण हमारे पास GetSchemaTable() नहीं हो सकता है, तो यह एक बात है, लेकिन इंटरफेस को अभी भी बहाल किया जाना चाहिए (यदि आवश्यक हो तो GetSchema के बिना) और उन पर गहरी निर्भरता के साथ मौजूदा कोड बेस को आसानी से पोर्ट करना। लापता इंटरफेस एक अवरोधक हैं, मैं अभी भी उनके साथ रिलीज की प्रतीक्षा कर रहा हूं इससे पहले कि हम dnx/core का समर्थन करने के लिए काम शुरू कर सकें।

मैं @mythz से सहमत

सच कहूं तो, 'आरटीएम' लेबल की ओर अत्यधिक दबाव के साथ, मुझे उम्मीद नहीं है कि हमें 1.0 के साथ एक ठोस एपीआई मिलेगा। यह फिर से .NET 2.0 जैसा होगा: पहले संस्करण द्वारा की गई सभी गलतियों को फिर सुधारा जाएगा।

@FransBouma

.NET कोर में इंटरफेस जोड़ना एक योगात्मक परिवर्तन होगा। तो अगर यह V1 के लिए कटौती नहीं करता है, तो इसे किसी भी संस्करण में जोड़ा जा सकता है, यहां तक ​​​​कि 1.1 भी।

फिर पहले संस्करण द्वारा की गई सभी गलतियों को ठीक किया जाएगा।

कोई अपराध नहीं है, लेकिन इस तरह सॉफ्टवेयर काम करता है।

@terrajobst

तो अगर यह V1 के लिए कटौती नहीं करता है, तो इसे किसी भी संस्करण में जोड़ा जा सकता है, यहां तक ​​​​कि 1.1 भी।

हाँ, ऐसा नहीं है कि यह तकनीकी रूप से संभव नहीं है, यह है कि ऐसा करने के परिणाम (या ऐसा करने की कमी) के (दूरगामी) परिणाम हैं, जिनमें से Microsoft पीड़ित नहीं है, वह हम हैं। अब तक मैंने इसके लिए थोड़ी सी उदासीनता देखी है। नए ढांचे पर काम करना बहुत अच्छा और रोमांचक है, लेकिन इसे नए दर्शकों के लिए एक साफ कमरे में विकसित नहीं किया गया है। ऐसा भी नहीं है कि इसके विपरीत सीखने के लिए कोई इतिहास नहीं है।

कोई अपराध नहीं है, लेकिन इस तरह सॉफ्टवेयर काम करता है।

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

मुझे पता है कि सॉफ्टवेयर कैसे काम करता है, मैं 21 वर्षों से अधिक समय से एक पेशेवर सॉफ्टवेयर डेवलपर हूं। मैंने एक नौसिखिया के रूप में नहीं बल्कि इस विशेष क्षेत्र में एक युद्ध-कठोर विशेषज्ञ के रूप में अपनी ईमानदार सलाह दी। आप इसके साथ जो चाहें कर सकते हैं, मुझे आशा है कि आप यहां हल्के में निर्णय लेने से पहले दो बार सोचेंगे, क्योंकि परिणाम दूरगामी हैं, और जैसा कि मैंने कहा: हमें इनसे निपटना है, आपको नहीं।

एक गलती भी बाद में ठीक की जा सकती है, लेकिन यह अभी तक नहीं की गई है, यह पहली जगह में न करने का एक अच्छा कारण है, है ना?

आप लोग ओवररिएक्ट कर रहे हैं। मुझे संदेह है कि इसके प्रभाव पुराने .NET के समान ही होंगे।

प्रत्येक एप्लिकेशन के भीतर कोरक्लर बंडल के साथ, विरासत का एक बहुत अलग अर्थ होता है। एएसपीएनटी एमवीसी 5 की सुविधाओं को एमवीसी 4 या 3 में बैकपोर्ट नहीं किया गया है, तो बहुत ज्यादा कोई परवाह नहीं करता है। यहां विरासत का एक अलग अर्थ होगा, और यह दिखाने के लिए अन्य परियोजनाओं में इतिहास है।

अच्छी बात है @terrajobst अगले संस्करणों के लिए इस पर विचार करने के लिए खुला है।

@nvivo कृपया परिणामों को कम करने की कोशिश न करें _I_ से निपटना है, क्योंकि आपको उनसे निपटने की ज़रूरत नहीं है, लेकिन मैं करता हूं।

धन्यवाद @FransBouma मुझे मेरी जगह पर रखने के लिए। यह सोचना मेरी गलती थी कि मैं इस मुद्दे पर टिप्पणी कर सकता हूं। आप निश्चित रूप से मुझसे अधिक योग्य हैं कि यह जानने के लिए कि किस तरह की चीजें मेरे काम को प्रभावित करती हैं।

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

मुझे वास्तव में खुशी है कि आप जैसे लोग कठिन समस्याओं का ध्यान रखने के लिए यहां हैं। कृपया बेझिझक हमें बार-बार और बार-बार (और बार-बार) बताएं कि _आप_ को और कितने महत्वपूर्ण मुद्दों से निपटना है।

धन्यवाद @FransBouma।

_sigh_ मैं वह सब कहाँ कहूँ? मैं केवल इतना कहता हूं कि कृपया चीजों को कम मत आंकें, जैसा कि आप 'आप अति प्रतिक्रिया कर रहे हैं' के साथ करते हैं, मुझे नहीं लगता कि मैं ओवररिएक्ट कर रहा हूं। 'आपको उनसे निपटने की ज़रूरत नहीं है' से मेरा मतलब है: _me_ के परिणाम। क्योंकि मुझे पता है कि वे क्या हैं, मैंने जिस तरह से प्रतिक्रिया दी है। जाहिर तौर पर यह 'ओवररिएक्टिंग' है।

जो कुछ भी लेकिन।

हमारे पास इस मुद्दे के उत्तर यहां और यहां हैं ।

आधिकारिक उत्तर है: इंटरफेस .NET कोर 1.0 पर नहीं होंगे, और हालांकि संभावना नहीं है, उन्हें .NET पर मौजूद कुछ अलग रूप में भविष्य में रिलीज के लिए माना जा सकता है।

मैं इस मुद्दे को बंद कर रहा हूं क्योंकि मूल प्रश्न को संबोधित किया गया था।

@nvivo धन्यवाद, लेकिन परियोजना के लिए वास्तव में जिम्मेदार लोगों को किसी भी आधिकारिक प्रतिक्रिया को छोड़ने के लिए सबसे अच्छा है, जो इसे हल करने का निर्णय लेने के बाद स्वयं मुद्दों को बंद करने में सक्षम हैं।

@terrajobst क्या इंटरफेस के लिए कोई अद्यतन आधिकारिक प्रतिक्रिया/समयरेखा है? और आगे चलकर इस कार्य आइटम को ट्रैक करने का सबसे अच्छा तरीका क्या है? क्या हमें एक नया मुद्दा खोलना चाहिए या आप यहां कोई अपडेट देना जारी रखेंगे?

आइए इसे अभी के लिए खुला छोड़ दें। जिस तरह से मैं इसे देखता हूं, जवाब "आइए इंटरफेस का पर्दाफाश न करें" नहीं था। जवाब था "आइए उन्हें बेनकाब करने का एक तरीका खोजें लेकिन आइए सोचें कि डेटाटेबल निर्भरता के लिए इसका क्या अर्थ है"।

आप लोगों के पास इतनी देर से वापस आने के लिए खेद है। हमारी टीम के भीतर विभिन्न विकल्पों पर चर्चा करने के बाद, हमने डेटाटेबल के एक खाली वर्ग के साथ इंटरफेस को वापस लाने का फैसला किया। यह एक आदर्श समाधान नहीं है, लेकिन आरटीएम की समय सीमा को देखते हुए, यह दृष्टिकोण सुनिश्चित करेगा कि हम भविष्य में डेटाटेबल/डेटासेट के आसपास व्यवहार्य विकल्पों का पीछा कर सकते हैं। हम v1 RTM द्वारा System.Data.Common के लिए इंटरफेस लाने का प्रयास करेंगे; SqlClient इंटरफेस को v1 द्वारा लागू नहीं करेगा। आपकी प्रतिक्रिया और धैर्य के लिए धन्यवाद। डेटा स्टैक को व्यवहार्य उत्पाद बनाने के लिए आपकी प्रतिक्रिया एक महत्वपूर्ण हिस्सा है।

अद्यतन के लिए @YoungGah thx, यदि

@mythz लागत मूल प्रकार में इंटरफेस को लागू करने/मौजूदा तरीकों को अग्रेषित करने में है। लागत न्यूनतम होनी चाहिए, लेकिन आमतौर पर चीजें दिखाई देती हैं: मुस्कान:

हमने System.Data.Common में .Net CoreFX में निम्नलिखित इंटरफेस जोड़े हैं

आईडीटा पैरामीटर
आईडीटा पैरामीटर संग्रह
आईडीटा रीडर
IDataRecord
आईडीबीकमांड
आईडीबी कनेक्शन
आईडीबीडेटा पैरामीटर
आईडीबी लेन-देन

यह पीआर में किया गया था https://github.com/dotnet/corefx/pull/6359

@ सौरभ 500 बढ़िया सामान, thx!

:+1:

:+1:

बहुत बढ़िया; क्या इसके लिए नगेट हिट करने के लिए कोई मील का पत्थर है? आरसी3?

२५ फरवरी २०१६ को ०२:५४ बजे, सौरभ सिंह नोटिफिकेशन @github.com
लिखा था:

हमने System.Data.Common में .Net CoreFX में निम्नलिखित इंटरफेस जोड़े हैं

आईडीटा पैरामीटर
आईडीटा पैरामीटर संग्रह
आईडीटा रीडर
IDataRecord
आईडीबीकमांड
आईडीबी कनेक्शन
आईडीबीडेटा पैरामीटर
आईडीबी लेन-देन

यह PR dotnet/corefx#6359 https://github.com/dotnet/corefx/pull/6359 में किया गया था

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/dotnet/corefx/issues/3480#issuecomment -188577701।

सादर,

न घुलनेवाली तलछट

जैसा कि पीआर पर टिप्पणी की गई है, हमें यह समझने की जरूरत है कि इन इंटरफेस पर एसिंक्स तरीके क्यों नहीं हैं। जैसा कि प्रस्तावित किया गया था, यह मूल रूप से ADO.NET 1.1 इंटरफेस का एक छोटा संस्करण है, और मुझे नहीं लगता कि विचार केवल पुराने कोड के साथ संगतता होना चाहिए।

इंटरफ़ेस को ado.net की वर्तमान स्थिति पर ध्यान केंद्रित करना चाहिए, क्योंकि आज किसी भी डेटाबेस तक पहुँचने के लिए async विधियाँ डिफ़ॉल्ट तरीका होनी चाहिए। एसिंक विधियों के वास्तविक समर्थन के बिना, ये इंटरफेस आधुनिक विकास के लिए बेकार हैं
विकास।

और यहां तक ​​कि .NET 4.5 से async विधियों सहित, कुछ अतिरिक्त विधियों, जैसे DbTrabsaction.CommitAsync को भी जोड़ा जाना चाहिए।

पोस्टग्रेज प्रदाता ने कुछ अतिरिक्त तरीके जैसे CommitAsync को अपने एपीआई में जोड़ा जो काफी उपयोगी और आवश्यक हैं।

वर्तमान इंटरफेस ठीक हैं जैसे वे हैं। उन्हें बदलने का निहितार्थ अभी बहुत बड़ा है।

एसिंक्स मॉडल सिंक्रोनस मॉडल से काफी अलग है और जैसा कि आप जानते होंगे, अगर आप एसिंक्स मॉडल के लिए जाते हैं तो आपको इसे पूरी तरह से करना चाहिए। इसलिए दोनों एपीआई के लिए समान इंटरफेस रखने का वास्तव में कोई कारण नहीं है। async API के लिए नए बनाएँ।

यदि .NET टीम अधिक आधुनिक API प्रदान करना चाहती है, तो क्यों न केवल एक नया API बनाया जाए जिसे ADO.NET नहीं कहा जाता है? कोई विरासत बाधा नहीं है और समुदाय से कोई शिकायत नहीं है। यह भी अच्छी तरह से फिट बैठता है कि कैसे dnx वितरित किया जा रहा है? यानी स्वतंत्र पैकेज।

:+1: इंटरफेस पर, अच्छा समझौता।

मुझे नहीं लगता कि विचार केवल पुराने कोड के साथ संगतता होना चाहिए।

वह यहाँ _संपूर्ण_ विचार है। अन्यथा, आधार वर्ग ठीक रहेगा। यह बहुत अधिक पोर्टिंग दर्द है जिससे हम बचना चाहते हैं।

एसिंक्स विधियों के वास्तविक समर्थन के बिना, ये इंटरफेस आधुनिक विकास के लिए बेकार हैं।

मैं इससे असहमत हूं, लेकिन मैं जरूरी इंटरफेस के एसिंक संस्करण से असहमत नहीं हूं (जिसे आज कोई भी लागू नहीं करता है)। यह एक नया फीचर होगा। हम मौजूदा इंटरफेस में सदस्यों को पूर्वव्यापी रूप से नहीं जोड़ सकते हैं, जो कि बहुत सी चीजों को तोड़ देता है। IDbReaderAsync या कुछ पागल आईएमओ नहीं है, लेकिन यह एक अलग चर्चा है।

मैं दृढ़ता से मानता हूं कि async विधियों को आधार वर्गों पर _not_ होना चाहिए, यदि डिफ़ॉल्ट कार्यान्वयन एक सिंक रैपर है - यह सक्रिय रूप से खराब और बेकार है। अगर वहाँ एक और प्रस्ताव है तो ऐसा ही हो, लेकिन फिर से: वैसे भी यह एक अलग मुद्दा होना चाहिए।

ठीक है, हो सकता है कि मैंने यहां अपने आप को गलत तरीके से व्यक्त किया हो या अपने शब्दों के साथ बहुत मजबूत था।

यदि आवश्यक हो तो मैं async के लिए एक अतिरिक्त इंटरफ़ेस के पक्ष में हूँ। जो मैं ठीक नहीं हूं उसके साथ कुछ ऐसा है जो ADO.NET के लिए आधिकारिक अनुबंध को परिभाषित करता है (यही इंटरफेस है) लेकिन इसमें कहीं भी एसिंक विधियां नहीं हैं।

लेकिन फिर, एसिंक विधियों के लिए वैकल्पिक इंटरफेस होने से शायद अन्य समस्याएं हो सकती हैं ...

मैं दृढ़ता से मानता हूं कि एसिंक विधियां आधार वर्गों पर नहीं होनी चाहिए, यदि डिफ़ॉल्ट कार्यान्वयन एक सिंक रैपर है - यह सक्रिय रूप से खराब और बेकार है।

मैं सहमत हूं, यही मुख्य कारण है कि अधिकांश प्रदाता वास्तविक एसिंक एपीआई को लागू करने से परेशान नहीं होते हैं। लेकिन इसे बदलने से बहुत अधिक कोड टूट जाएगा और संभवत: इंटरफेस को हटाने की तुलना में बहुत अधिक शोर होगा, क्योंकि आधार वर्ग 2.0 के बाद से प्रदाताओं के लिए वास्तविक एपीआई रहा है।

1.1 इंटरफेस में से किसी का उपयोग नहीं करने के लिए लाइब्रेरी को अपग्रेड करने से पिछले वर्षों में लिखे गए सभी एसिंक कोड को हटाने की तुलना में लगभग शून्य प्रभाव पड़ेगा, जो विनाशकारी होगा। समझौता दोनों हो रहा है। आज लिखा गया कोई भी कोड async apis का उपयोग करना चाहिए, इसलिए इसे छोड़ने का कोई मतलब नहीं है।

आज लिखा गया कोई भी कोड async API का उपयोग करना चाहिए।

मैं बहुत कठोर घाव नहीं करना चाहता, लेकिन वह आदर्श दुनिया वास्तविकता से बहुत दूर है। Async बहुत व्यापक और संक्रामक है। आप केवल पुस्तकालयों में एसिंक एपीआई पर भरोसा नहीं कर सकते हैं और पूरे एप्लिकेशन को एसिंक उपभोक्ता होने की उम्मीद कर सकते हैं (उनके कोड के _ton_ को भी एसिंक में बदल सकते हैं)। सिंक -> हर जगह Async भी बहुत सारे गतिरोध और दक्षता कारणों से बहुत खराब है। आने वाले कई सालों तक सिंक्रोनस कोड लिखा जाएगा।

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

पिछले वर्षों में लिखे गए सभी एसिंक्स कोड को हटाने की तुलना में 1.1 इंटरफेस में से किसी का उपयोग नहीं करने के लिए लाइब्रेरी को अपग्रेड करने से लगभग शून्य प्रभाव पड़ेगा

आप द्वारा किसे संदर्भित किया जा रहा है? इस तरह के कोड के अस्तित्व के लिए कोई एसिंक एपीआई नहीं है। यदि आप ऐसे एपीआई पर भरोसा कर रहे हैं तो वे बेस क्लास या इंटरफेस पर नहीं हैं, बल्कि सीधे प्रदाता पर हैं। इससे यह प्रभावित नहीं होगा।

आज लिखा गया कोई भी कोड async apis का उपयोग करना चाहिए, इसलिए इसे छोड़ने का कोई मतलब नहीं है।

बहुत सी चीजों को छोड़ देने का कोई मतलब नहीं है... इस तथ्य को छोड़कर कि हम सभी संसाधनों (विशेषकर समय) से विवश हैं। मुझे विश्वास नहीं है कि किसी ने कुछ भी _स्थायी रूप से_ छोड़ दिया है। मेज से कुछ भी नहीं है। यह बस अभी तक नहीं मिला है। मैं विशेष रूप से भविष्य की पीढ़ी के लिए एसिंक इंटरफेस पर एक स्पेक शुरू करने के लिए एक और मुद्दा खोलूंगा।

आप द्वारा किसे संदर्भित किया जा रहा है? इस तरह के कोड के अस्तित्व के लिए कोई एसिंक एपीआई नहीं है। यदि आप ऐसे एपीआई पर भरोसा कर रहे हैं तो वे बेस क्लास या इंटरफेस पर नहीं हैं, बल्कि सीधे प्रदाता पर हैं। इससे यह प्रभावित नहीं होगा।

.NET 4.5 ने प्रदाता आधार वर्गों पर async विधियों की शुरुआत की। यह लगभग 4 साल पहले 2012 में था, इसलिए यह कुछ समय के लिए ADO.NET प्रदाता API का हिस्सा रहा है। Entity Framework 6 (2013 को जारी) सभी प्रदाताओं के लिए इस async API पर निर्भर करता है।

Async विधियां पहले से ही पर्याप्त समय के लिए ADO.NET का हिस्सा हैं कि अगर .NET कोर में शामिल नहीं किया गया तो बहुत से लोग चिल्लाएंगे। मेरे पास _legacy code_ है जो ADO.NET में async विधियों का उपयोग करता है।

मैं इस बात की वकालत कर रहा हूं कि चूंकि वे ADO.NET का _पहले से ही हिस्सा हैं, इसलिए यह नए इंटरफ़ेस API पर भी मौजूद होना चाहिए।

यदि लोग async API का उपयोग करना चाहते हैं (और उन्हें करना चाहिए), तो वे पहले से ही कर सकते हैं
कि _इस परिवर्तन से पहले_ आधार प्रकारों का उपयोग करके। अंत में, अनुरोध
पश्च संगतता कारणों के लिए इंटरफेस का समर्थन करने के लिए बनाया गया था;
इंटरफ़ेस में विधियों को जोड़ने से _इसे पूरी तरह से पानी से बाहर निकाल देता है_।
उस ने कहा, यह वास्तव में _extension विधियों_ और . के रूप में संभव है
सार आधार-प्रकार के खिलाफ टाइप-चेकिंग, लेकिन ... बहुत बदसूरत और नहीं
दर्द के लायक आईएमओ।

इसलिए; लघु संस्करण: मैं व्यक्तिगत रूप से async को जोड़ने के पीछे नहीं जा सकता
इंटरफेस, क्योंकि यह उस एक चीज को नष्ट कर देता है जिसके लिए हम उन्हें पहले चाहते थे
जगह। यदि आप async चाहते हैं: आपको बेस-क्लास के विरुद्ध कोड करना होगा, या उपयोग करना होगा
उपकरण जो आपके लिए इन विवरणों पर प्रकाश डालते हैं।

मैं इस बात की वकालत कर रहा हूं कि चूंकि वे पहले से ही ADO.NET का हिस्सा हैं, इसलिए यह नए इंटरफ़ेस API पर भी मौजूद होना चाहिए।

आप इन ADO.NET इंटरफेस के उद्देश्य को पूरी तरह से गलत समझ रहे हैं जो मौजूदा कोड के साथ संगतता बनाए रखना है। ये _new_ इंटरफेस नहीं हैं, ये _मौजूदा_ इंटरफेस हैं। यदि आप नए एपीआई का उपयोग करना चाहते हैं, तो ठोस आधार प्रकारों का संदर्भ लें।

@nvivo क्षमा करें, मैं आपका अनुसरण नहीं कर रहा हूं - मैं _interface_ API के बारे में बात कर रहा था - वे कभी अस्तित्व में नहीं थे। मूल प्रकारों में पहले से ही सभी समान *Async विधियां हैं - क्या कुछ विशिष्ट है जो गुम है? मुझे लगता है कि आप तर्क दे रहे हैं कि उन्हें इंटरफेस में बंडल किया जाना चाहिए ... हाँ, लेकिन यह एक और मुद्दा है जिसे मैं आपको खोलने के लिए प्रोत्साहित करता हूं।

मैं शुरू से ही एक इंटरफ़ेस रहा हूं क्योंकि वर्तमान दृष्टिकोण को काम करने के लिए आवश्यक आधार कार्यान्वयन (सिंक पर एसिंक) पूरे दृष्टिकोण को काम करने के लिए भयानक ट्रेडऑफ हैं। लेकिन, हमारे पास यह दोनों तरीके नहीं हो सकते हैं: या तो वे इंटरफेस में चले जाते हैं या वे मौजूद हैं (जैसा कि वर्तमान मामला है) ब्रेक को कम करने के लिए।

हाँ, मुझे लगता है कि हम यहाँ मंडलियों में जा रहे हैं। मैंने पहले यह कहा था, मुझे नहीं लगता कि पोर्टिंग कोड में मदद के लिए इंटरफेस को _just_ जोड़ा जाना चाहिए। संगतता के दृष्टिकोण से, आधार वर्ग 2005 से ADO.NET के लिए आधिकारिक API रहा है, और यही प्रदाता लागू करते हैं। आईडीबीकॉमैंड या आईडीबीकनेक्शन का उपयोग करने वाली किसी भी चीज़ को आसानी से पोर्ट किया जा सकता है (और पोर्ट किया जाना चाहिए) बेस क्लास का उपयोग खोज/प्रतिस्थापन के साथ करने के लिए किया जा सकता है और इसमें कोई डाउनसाइड नहीं है।

मुझे पता है कि आप ifdefs के प्रशंसक नहीं हैं, लेकिन एक नए प्लेटफॉर्म के लिए इसका समर्थन करना वैसे भी केवल माइग्रेशन का हिस्सा होगा।

मैं मानता हूं कि यह सभी इंटरफेस होना चाहिए था, लेकिन चूंकि वे नहीं थे, इसलिए मैं यह देखना चाहता हूं कि यह समस्या खुद को दोहराए नहीं। यदि इंटरफेस जोड़े जा रहे हैं, तो उन्हें कम से कम वर्तमान एपीआई का प्रतिनिधित्व करना चाहिए, न कि एक दशक पहले जो वे थे। Async विधियाँ वर्तमान API का एक अभिन्न अंग हैं और इसी दिशा में Microsoft काफी समय से आगे बढ़ रहा है। यह अभी भी स्रोत संगत होगा, बस और अधिक पूर्ण होगा।

@mgravell

यदि लोग एसिंक्स एपीआई का उपयोग करना चाहते हैं (और उन्हें करना चाहिए), तो वे पहले से ही आधार प्रकारों का उपयोग करके _इस परिवर्तन से पहले_ कर सकते हैं।

यह कुछ भी करने में सक्षम होने के बारे में नहीं है। यह वास्तुकला के बारे में है। इंटरफेस अनुबंध हैं, .NET कोर एक नया ढांचा है जो इस अनुबंध को एपीआई के पुन: डिज़ाइन किए गए संस्करण में जोड़ रहा है।

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

अगर वह सब टीम कर रही है, तो ठीक है .. यह सिर्फ एक बुरा विकल्प है आईएमओ।

आईडीबीकॉमैंड या आईडीबीकनेक्शन का उपयोग करने वाली किसी भी चीज़ को आसानी से पोर्ट किया जा सकता है (और पोर्ट किया जाना चाहिए) बेस क्लास का उपयोग खोज/प्रतिस्थापन के साथ करने के लिए किया जा सकता है और इसमें कोई डाउनसाइड नहीं है।

झूठा। इस धागे में कई बार पुस्तकालय के लेखकों से मुद्दों पर चर्चा की गई है, जो इससे प्रभावित हुए हैं।

मुझे पता है कि आप ifdefs . के प्रशंसक नहीं हैं

किसी भी समाधान के लिए अंतिम ग्राहकों को ifdefs का उपयोग करने की आवश्यकता होती है, एक टूटा हुआ देव अनुभव और एक गैर-स्टार्टर है, अर्थात ऐसा कोई सफल उत्पाद कभी नहीं होगा जिसके लिए ग्राहकों को विकल्प मौजूद होने पर #defs के साथ अपना कोड डालना होगा।

यदि इंटरफेस जोड़े जा रहे हैं, तो उन्हें कम से कम वर्तमान एपीआई का प्रतिनिधित्व करना चाहिए

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

इस धागे में अब कोई नया मूल्य नहीं जोड़ा जा रहा है। मौजूदा ADO.NET इंटरफेस को बहाल कर दिया गया है ताकि इस धागे को आराम दिया जा सके। इस थ्रेड से केवल DataTable और GetSchemaTable() अपडेट की जरूरत है क्योंकि वे मौजूदा इंटरफेस से संबंधित हैं। यदि आप वास्तु परिवर्तन का प्रस्ताव देना चाहते हैं या नए इंटरफेस की वकालत करना चाहते हैं, तो एक नया मुद्दा खोलें - जो इस सूची में सभी को स्पैम होने से रोकेगा।

@mythz असहमत होने के लिए सहमत हैं।

बस एक और ओआरएम डेवलपर के रूप में मेरे 2 सेंट जोड़ना, इंटरफ़ेस द्वारा समर्थित नहीं होने पर अमूर्त वर्ग हमेशा एक कोड गंध होते हैं। न्यूनतम आवश्यकता इंटरफ़ेस एपीआई के साथ अतिभारित अमूर्त वर्गों और विधि हस्ताक्षरों से मेल खाने के लिए प्रदान किए गए नए इंटरफेस देखना पसंद करेंगे।

बोलने के लिए समुदाय के लिए अंगूठे।

इंटरफ़ेस द्वारा समर्थित नहीं होने पर अमूर्त वर्ग हमेशा एक कोड गंध होते हैं

@psibernetic क्या आप उस कथन को समझने में मेरी सहायता कर सकते हैं? इसके बारे में एक कोड गंध क्या है?

@psibernetic

इंटरफेस और अमूर्त वर्ग हमें अनुबंध देते हैं, दोनों हमें एपीआई के लिए एक अमूर्त और एक अच्छी परिभाषा देते हैं। इंटरफेस सबसे उपयोगी होते हैं जब कक्षाओं को लागू करते हैं जो एक से अधिक इंटरफेस को लागू कर सकते हैं या किसी अन्य बेस क्लास के उप-वर्ग हैं (यह मानते हुए कि उस बेस क्लास का एक बहुत बड़ा फायदा है)। इस मामले में विशेष रूप से, विशिष्ट प्रदाताओं के लिए कनेक्शन, कमांड, और इसी तरह के ठोस वर्गों का सार एपीआई परिभाषाओं के साथ एक मजबूत आईएस ए संबंध है। मैं वास्तव में एक परिदृश्य की कल्पना नहीं कर सकता जब कुछ डेवलपर को एक उपवर्ग में IDbConnection या IConnection के लिए एक ठोस कार्यान्वयन जोड़ने की आवश्यकता होती है। लगभग एकमात्र परिदृश्य नए वर्ग होंगे जो केवल अमूर्त वर्ग के लिए प्राप्त होते हैं और इंटरफ़ेस पर समान परिभाषा को "डुप्लिकेट" करने के लिए एपीआई डिजाइनर के लिए अधिक काम (अनावश्यक) होता है।

क्या आप दो समान अमूर्तताओं के लिए एक विशिष्ट और ठोस लाभ या परिदृश्य देखते हैं? जब इंटरफ़ेस इस विशिष्ट एपीआई डिज़ाइन में अमूर्त वर्ग को व्यावहारिक और वास्तविक लाभ _over_ प्रदान करता है?

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

@eocampo आप सही हैं कि अमूर्त वर्ग शायद "पर्याप्त पर्याप्त" अमूर्तता और अनुबंध प्रदान करते हैं। मैं हमेशा बहुत संकीर्ण इंटरफेस प्रदान करने का प्रयास करता हूं जो कि IAsyncCommand और पसंद जैसे कार्यों का प्रतिनिधित्व करते हैं। यह मेरे ढांचे को उन तरीकों से प्लग इन करने की इजाजत देता है जिन्हें ढांचे के डिजाइन समय पर भयानक समर्थित नहीं किए गए अपवादों या लागू नहीं किए गए अपवादों के कम मौके के साथ नहीं माना जा सकता है।

@davkean कोड गंध यह है कि ज्यादातर मामलों में, हालांकि सभी नहीं, आपको एक कार्यान्वयनकर्ता को कार्यक्षमता के पूरे आधार सेट को लागू करने या प्राप्त करने की आवश्यकता होती है जो प्रासंगिक नहीं हो सकता है। मुझे IDataReader कार्यान्वयन देखना याद है जो इसके बजाय कैश या मेमोरी से पढ़ता है। सुनिश्चित नहीं है कि DbDataReader अमूर्त वर्ग इसकी अनुमति देगा, लेकिन नाम का तात्पर्य नहीं है।

डॉट नेट में मुख्य रूप से पालन किए जाने वाले सर्वोत्तम अभ्यास मॉडल इंटरफेस का पर्दाफाश कर दिया गया है और बेस क्लास से विरासत में मिला है?

डॉट नेट में मुख्य रूप से पालन किए जाने वाले सर्वोत्तम अभ्यास मॉडल इंटरफेस का पर्दाफाश कर दिया गया है और बेस क्लास से विरासत में मिला है?

@psibernetic हमेशा नहीं। उदाहरण के लिए MSDN साइट पर इस अनुशंसा को एक दशक से अधिक समय हो गया है। और वह दिशानिर्देश कम से कम .Net Framework 2.0 से बहुत आम है।

साथ ही यह शुरुआती दिनों से .Net में पुस्तकालय डिजाइन के लिए दिशा-निर्देशों का एक अच्छा संदर्भ है:

http://www.amazon.com/Framework-Design-Guidelines-Conventions-Libraries/dp/0321545613

वैसे भी मुझे लगता है कि यहाँ कठिन चर्चा अब लगभग दो विषयों पर है:

ए) इंटरफेस केवल पिछड़े संगतता के लिए हैं या क्या हम क्लीनर इंटरफेस और एपीआई डिज़ाइन की अनुमति देने के लिए "स्क्रैच से शुरू" (ब्रेकिंग कोड) कर सकते हैं।
b) हम पूर्ण .NET ढांचे के अनुकूल न होने की कीमत पर एक आधुनिक और स्वच्छ डिजाइन के लिए कितना जा सकते हैं। (विशेष रूप से डेटा एक्सेस पर नेट कोर और पूर्ण कोर के बीच संगतता [सबसे निम्न स्तर और अनिवार्य संगतता नहीं])

मेरे दृष्टिकोण से, यदि हमारे पास प्राथमिक और पसंदीदा अनुबंध के रूप में सार आधार वर्ग हैं, तो _interfaces_ को केवल संगतता के लिए पुराने से मेल खाना चाहिए। मैं समझता हूं कि @nvivo ने पहले ही कहा है कि .Net 2.0 के बाद आधिकारिक अनुबंध अमूर्त आधार वर्ग था, इसलिए हम _could_ सोच सकते हैं कि इंटरफेस संगतता समस्या का समाधान नहीं करेंगे, लेकिन @mythz और @mikeobrien ने प्रदाताओं की निर्भरता के बारे में यहां कठिन डेटा भी प्रदान किया था। 1.1 इंटरफेस पर।

स्पैमिंग को रोकने और यहां विषयों पर चर्चा करने के लिए हमें इस लंबी बातचीत को फिर से पढ़ना होगा और मुझे नहीं पता कि क्या हम उन विशिष्ट विषयों की सूची पर सहमत हो सकते हैं जिन्हें हम संबोधित कर रहे हैं या यदि दो या तीन नए बनाना एक अच्छा विचार है प्रत्येक विशिष्ट विषय के लिए मुद्दे। मैं पहले सुझाव में से अधिक हूं क्योंकि यहां बहुत सारे अच्छे बिंदु हैं। मुझे इस बात का अच्छा अंदाजा नहीं है कि हम इन सभी को फिर से कैसे सारांशित कर सकते हैं और कुछ शोर (यहां तक ​​कि मेरा भी) को साफ कर सकते हैं।

इंटरफेस की बात करें तो, क्या सिस्टम के कुछ हिस्सों को बनाने की योजना है। डेटा जेनेरिक? इसने मुझे हमेशा परेशान किया है कि System.Data को वास्तव में .NET 1.1 से आगे अपना एपीआई अपडेट नहीं मिला है, जिससे लोगों को IEnumerable प्राप्त करने के लिए .AsEnumerable() एक्सटेंशन विधि जैसे हैक्स का उपयोग करना पड़ता है।डेटाटेबल से बाहर। DataRowCollection जैसे संग्रहों को जेनेरिक इंटरफेस को लागू करने के लिए अपग्रेड क्यों नहीं किया गया है, जब 2.0 के बाहर आने पर फ्रेमवर्क में बाकी सब कुछ किया गया था?

क्या इसमें एक स्टब System.Data होगा जिसमें टाइप रीडायरेक्शन होगा? मुझे ODP.NET का उपयोग करने की आवश्यकता है लेकिन अब मैं नहीं कर सकता।

बनाया गया डॉटनेट/कोरएफएक्स#7874

@mgravell @ploeh "रिकसॉरस" निहित टाइपक्लास क्षितिज पर थे (एफ # के लिए, कम से कम, सी # या .NET के बारे में निश्चित नहीं है https://news.ycombinator.com/threads?id=Rickasaurus)। अगर ऐसा है कि वे सभी .NET के लिए आ रहे हैं, तो क्या इससे समस्या का समाधान होगा?

मैं हास्केल विशेषज्ञ नहीं हूं, लेकिन मेरी समझ यह है कि वे आपको एक साधारण IDbConnection , IDbConnectionAsync , और किसी भी भविष्य के साझा इंटरफेस पर बिना किसी स्रोत को तोड़े या बाइनरी संगतता, और तृतीय-पक्ष प्रदाताओं को सब कुछ लागू करने के लिए मजबूर किए बिना। यह आसान नकलीपन बनाए रखते हुए।

क्या यह सही समझ है? यदि हां, तो क्या इस सुविधा के .NET में वास्तविक रूप से आने की कोई संभावना है?