كانوا سيتحولون إلى فئات أساسية مجردة لأن الواجهات لا يمكن إصدارها.

أظن أن الأساليب غير الافتراضية تستدعي طريقة أخرى افتراضية. تضر الأساليب الافتراضية بالأداء ، لذا لا تريد جعل الأشياء افتراضية دون داع.

تضمين التغريدة ولكن نظرًا لكون NET Core واجهة برمجة تطبيقات جديدة وكون ADO.NET API مستقرًا تمامًا على مدار عقد تقريبًا ، هل تعتقد أن هذا لا يزال مصدر قلق صحيح؟ أيضًا ، بالحديث عن الوصول إلى قاعدة البيانات ، أعتقد أن تكلفة الأساليب الافتراضية تتضاءل أمام تكلفة الوصول إلى قاعدة البيانات.

NickCraver ، roji ، FransBouma حيث يبدو أن لديك اهتمامًا بـ ADO.NET API ، هل لديك ما تقوله حول هذا الأمر؟

YoungGah ، هل هذا شيء يستحق المتابعة؟

أظن أن الأساليب غير الافتراضية تستدعي طريقة أخرى افتراضية. تضر الأساليب الافتراضية بالأداء ، لذا لا تريد جعل الأشياء افتراضية دون داع.

في عملية تنفيذ استعلام على قاعدة بيانات بعيدة ومعالجة النتائج ، فإن النانو ثانية المفقودة على Virtcall لا تكاد تذكر. إلى جانب ذلك ، يستخدم ADO.NET هذا النظام منذ البداية (وكذلك الكثير من واجهات برمجة التطبيقات الأخرى في .NET) ولم يشتك أحد من أن رمز قاعدة البيانات الخاص به بطيء جدًا بسبب استدعاءات الطريقة الافتراضية ؛)

يمكنني رؤية طرق غير متزامنة في قائمتك ، لذا أعتقد أنه منذ عامين فقط لم يتمكن MS من إضافة غير متزامن إلى IDbCommand. من يدري ما سيأتي به غدًا سيتطلب أساليب أو خصائص جديدة.

واجهات لا تصدر.

الأداء هو سبب واحد فقط لعدم عمل شيء افتراضي. ربما تقليل مساحة السطح للادعاءات؟ سأترك شخصًا ما في MS يقول لماذا قرروا عدم القيام بذلك ، لا أعرف الكثير عن ADO.NET لذلك سأكون مجرد تخمين.

JamesNK أعتقد أن مخاوفك صحيحة ، ولكن هناك

1. كان ADO.NET مستقرًا إلى حد كبير منذ .NET 2.0 ، وهو عقد - على الرغم من إضافة واجهة برمجة التطبيقات غير المتزامنة لاحقًا ، إلا أنه لم يغير سلوك واجهة برمجة التطبيقات (API) ، فقط أضف نظرائهم غير المتزامنين - لا أرى أي تغييرات كبيرة في نموذج برنامج تشغيل قاعدة البيانات في أي وقت قريب
2. من المفترض أن يكون لدى CoreFx فكرة إصدار مختلفة ، حيث يمكنك الاحتفاظ بـ CLR السابق للتطبيقات القديمة. لذلك لا ينبغي أن يكون لقضايا إصدار الواجهة مثل هذا التأثير هنا

ضع في اعتبارك أيضًا أنه حتى خادم SQL على "المضيف المحلي" سينفق في الإيجار بضع مللي ثانية فقط للاتصال وإرجاع استعلام فارغ. عمليًا ، تستغرق معظم الاستعلامات _ fast_ لقواعد البيانات العلائقية حوالي 20 مللي ثانية.

تعد القدرة على الاستهزاء بواجهة برمجة التطبيقات باستخدام أدوات قياسية مثل NSubstitute أو Moq أكثر قيمة للمطور اليوم من توفير أجزاء من الثانية في عمليات البحث عن الطريقة الافتراضية.

أعتقد أنه ليس لدي رأي قوي هنا ، ولكن إليك بعض الملاحظات:

• توافق على ما سبق أن إزالة الظاهرية مقابل غير الظاهرية أمر لا يكاد يذكر في واجهة برمجة التطبيقات للوصول إلى قاعدة البيانات
• تسمح الفئات الأساسية لـ ADO.NET بتوفير تطبيقات ، وأعتقد أن هذا هو ما تدور حوله معظم الأساليب غير الظاهرية غير المجردة - الحمل الزائد على ExecuteReader الذي لا يقبل CommandBehavior يمرر CommandBehavior.Default إلى التحميل الزائد هذا يفعل. إذا قمت بالتبديل إلى الواجهات ، فسيتعين على كل مزود تنفيذ ExecuteReader () بنفس المعيار المعياري ...
• لست متأكدًا من أن هذا صالح في جميع أطر عمل المحاكاة الرئيسية ، ولكن على الأقل في Moq ، أليس من السهل الاستهزاء بفئة أساسية كما هي واجهة؟

لذا بشكل عام ، تبدو فكرة إسقاط الفئات الأساسية أو الواجهات جيدة (أبسط). نظرًا لأنني لا أرى أي ميزة للواجهات (إلا إذا كنت مخطئًا بشأن سهولة الاستهزاء) ، ويمكن للفئات الأساسية توفير وظائف مشتركة (أي الطرق غير الظاهرية غير المجردة) ، أعتقد أن أسلوب Microsoft في التخلص من الواجهات تبدو جيدة بالنسبة لي ...

أتفق مع roji على جميع نقاطه.

roji مجرد ملاحظة ، أنا لا أقترح إسقاط الفئات الأساسية ، أقترح إضافة الواجهات على أنها واجهة برمجة التطبيقات الافتراضية. لا يزال بإمكان الفئات الأساسية تنفيذ السلوك الافتراضي.

بالنسبة للاختبار ، واجهت مشكلات كبيرة في اختبار ما إذا كانت واجهة برمجة التطبيقات الخاصة بي تستدعي الأساليب الصحيحة. للتحقق مما إذا كان ExecuteDataReader قد تلقى المعلمات الصحيحة على سبيل المثال ، يجب عليك التحقق من طريقة محمية أخرى تسمى داخليًا بمعلمات مختلفة. هذا أبعد ما يكون عن المثالية.

حاليًا ، ما لم أكن مخطئًا ، فإن الإطار الوحيد الذي يمكنه أن يسخر من ADO.NET API هو إطار عمل MS Fakes الذي يمكن أن يسخر من أي شيء عن طريق اعتراض المكالمات. Moq والآخرون لا يستطيعون فعل ذلك.

أنا مهتم بمعرفة ما إذا كان لدى الأشخاص الآخرين مشكلات مماثلة.

roji مجرد ملاحظة ، أنا لا أقترح إسقاط الفئات الأساسية ، أقترح إضافة الواجهات على أنها واجهة برمجة التطبيقات الافتراضية. لا يزال بإمكان الفئات الأساسية تنفيذ السلوك الافتراضي.

آسف ، لقد أسأت فهم ذلك. في هذه الحالة ، أليس اقتراحك يحافظ على الأشياء كما هي في NET.

بالنسبة للاختبار ، واجهت مشكلات كبيرة في اختبار ما إذا كانت واجهة برمجة التطبيقات الخاصة بي تستدعي الأساليب الصحيحة. للتحقق مما إذا كان ExecuteDataReader قد تلقى المعلمات الصحيحة على سبيل المثال ، يجب عليك التحقق من طريقة محمية أخرى تسمى داخليًا بمعلمات مختلفة. هذا أبعد ما يكون عن المثالية.

إذا فهمت السيناريو الخاص بك (لست متأكدًا) ، فإن Moq's CallBase مفيد لهذا النوع من السيناريوهات - عمليات التنفيذ الافتراضية موروثة من الفئة الأساسية

roji

أليس اقتراحك أكثر أو أقل إبقاء الأشياء على ما هي عليه في .NET (لا يعني ذلك أن هناك أي خطأ في ذلك)؟

ليس تماما. تمت إضافة واجهة API في .NET 1.0 وإهمالها في 2.0. منذ 2.0 ، الواجهات موجودة للتوافق ، لكن لا توجد واجهة لـ ProviderFactory أو الفئات الأخرى في Data.Common. لا يوجد أيضًا أي شيء لواجهة برمجة التطبيقات غير المتزامنة أو 2.0 أو الأساليب الأحدث.

Moq يمكنه فقط أن يسخر من الأشياء التي يمكن الاستهزاء بها. يجب أن يكون هناك طريقة ما إما افتراضية أو مجردة يمكن تجاوزها ، أو طريقة محمية يمكنها الاتصال بها. توفر واجهة برمجة التطبيقات الحالية طريقة لبعض الحالات ، ولكن ليس لمعظمها. هناك العديد من الأشياء الداخلية والخاصة وبعيدة عن المنال ما لم تستخدم التفكير. يمكن فقط لـ MS Fakes القيام بذلك لأنه يستبدل المرجع برقاقة ، ولكن هذا متاح فقط في VS Enterprise وغير مجدية للمشاريع مفتوحة المصدر.

يبدو أن لدي حالة محددة للغاية ، ولكن بالتأكيد أي شخص حاول السخرية من واجهة برمجة التطبيقات هذه واجه هذه المشكلة. فقط google ، ينتهي كل حل تقريبًا بـ "محاكاة واجهة برمجة التطبيقات للواجهة القديمة أو إنشاء غلاف يمكنك تصوره":

nvivo حسنًا ، شكرًا على التفاصيل الإضافية - أعترف أنني لم أذهب بعيدًا في السخرية من ADO.NET.

الشيء الذي لا أفهمه هو سبب رغبتك في السخرية من الأساليب الداخلية والخاصة وغير المنال لواجهة برمجة التطبيقات. ألا يجب أن تسخر من الأساليب العامة المتاحة مباشرة لكود التطبيق الخاص بك (وهو ما تحاول اختباره)؟ أرى مشكلة في الأساليب غير الظاهرية (على سبيل المثال ، الحمل الزائد ExecuteReader () ذو المعلمة 0) ، ولكن بالنظر إلى أنه في ADO.NET ، فإن هذه دائمًا (؟) تستدعي بعض الحمل الزائد الظاهري (على سبيل المثال ، ExecuteReader (CommandBehavior)) ، هل هناك قضية حقيقية هنا؟

مجرد محاولة فهم سيناريو مشكلتك ، هل يمكنك إعطاء مثال بسيط؟

nvivo ليس لدينا حاليًا أي خطة لإدخال واجهات بسبب مشكلة الإصدار التي سبق أن أشار إليها العديد من الأشخاص في هذا الموضوع. من الأمثلة الجيدة على تأخر الواجهات عندما تمت إضافة طرق غير متزامنة وتدفق في .NET Framework 4.5. عندما أضفنا هذه الميزات الجديدة ، نظرنا بعناية في توسيع الواجهات. كانت الخيارات التي كانت لدينا في ذلك الوقت إما توفر InterfaceFooV2 أو واجهات منفصلة لـ asyn والبث. لم نرغب في إضافة InterfaceFooV2 حيث يمكننا توقع أننا نرغب في إضافة المزيد من واجهات برمجة التطبيقات في المستقبل. استمر في إضافة واجهات منفصلة لكل وظيفة جديدة سيكون مربكًا لأنها غير مرتبطة بالواجهات الحالية.

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();
    }
}

لا يجب تغيير واجهة IDbCommand أبدًا بعد إصدار DNX ويمكنك الاستمرار في إضافة وظائف باستخدام الإستراتيجية المذكورة أعلاه. يمكنك أيضًا لاحقًا (في إصدار كسر رئيسي) ، طي هذه الإضافات ودمجها في الواجهة الأساسية. في كلتا الحالتين ، نحصل على واجهات ADO.NET الأساسية الثابتة والتي تعتبر ضرورية لترحيل قواعد التعليمات البرمجية الحالية وبالتالي لاعتماد CoreCLR.

لقد طلب مني davkean تقديم أمثلة ملموسة عن تأثير إزالة واجهات ADO .NET الأساسية. لا أستطيع أن أتخيل أن هذا التغيير قد تم النظر فيه دون تقييم التأثير الهائل الذي سيحدثه على نظام NET. في ذلك لم يكن.

على الرغم من دور EF في كونها ORM الافتراضية لـ .NET ونجاحها البارز في الحصول على غالبية كبيرة من حصة السوق ، لا يزال هناك عدد كبير من مطوري .NET الذين يفضلون بدلاً من ذلك استخدام ORMs البديلة لعدد من الأسباب المختلفة. على سبيل المثال ، هناك ميزة مهمة من حيث صلتها بـ CoreCLR وهي أن لديهم دعمًا من الدرجة الأولى يعمل على Mono / Linux / OSX بالإضافة إلى دعم أنظمة RDBMS بديلة متعددة. نظرًا لأن CoreCLR يتقدم بشكل كبير لسوق مطوري Linux / OSX ، فكلما زاد الدعم المتاح لـ RDBM ، كان ذلك أفضل. سمة مهمة أخرى لمجتمع المطورين الذين يتبنون Micro ORM هو أنهم قاموا بالتقييم خارج الإعدادات الافتراضية للنظام البيئي MS لاختيار ORM الأنسب لهم. من كل ما رأيته ، هناك ارتباط كبير بين مطوري .NET OSS النشط (أي Anti-Dark Matter) والمطورين الذين يتبنون Micro ORMs ، وبالمثل أتوقع أن يكون لهذا ارتباط كبير مع المتبنين الأوائل لـ CoreCLR - الذي يتمثل عرض قيمته الرئيسية للتطوير على OSX / Linux. هذه بعض الأسباب التي تجعل من المفيد تضمين نظام .NET البيئي المحيط في اتخاذ القرار عند اتخاذ خيارات تصميم أساسية مثل هذه.

تنزيلات ORM البديلة

نظرة خاطفة على تنزيلات NuGet توفر مؤشرًا لما تبدو عليه الحصة السوقية غير التابعة لـ EF:

NHibernate - 1 مليون +
Dapper - 1 مليون +
OrmLite - 500 ألف +
Simple.Data - 300 ألف +
PetaPoco - ~ 100 ألف
NPoco -

الأرقام الحقيقية أكثر من ذلك بكثير حيث تم تصميم العديد من أجهزة Micro ORM مثل Dapper و Massive و PetaPoco و NPoco وما إلى ذلك لتلائم ملف cs. لذا لا يبلغ NuGet عن استخدامه الحقيقي. هناك أيضًا نظام ORM مغلق المصدر مثل LLBLGen Pro والذي يحتوي على قاعدة مستخدمين كبيرة ولكن لم يتم الإبلاغ عن استخدامه بواسطة NuGet ، وبالمثل أنا متأكد من أنني فاتني عددًا من أدوات ORM الأخرى التي نسيت / لا أعرف عنها.

التأثير على إدارة ORM البديلة

بفضل GitHub ، يمكننا إجراء بحث سريع لمعرفة عدد ملفات المصدر المختلفة التي تحتوي على النواة
واجهات ADO .NET IDbConnection و IDbCommand و IDataReader واجهات ADO .NET المتأثرة بهذا التغيير:

ملاحظة: هذه النتائج تظهر فقط ملفات المصدر ، والعدد الفعلي للمراجع المقطوعة أعلى من ذلك بكثير.

التأثير على رمز مصدر العميل

يمتد التأثير الفعلي لهذا التغيير أيضًا إلى جميع تبعيات المشاريع باستخدام إدارة الموارد البشرية هذه.
لسوء الحظ ، لا يقتصر التأثير على عمليات التنفيذ الداخلية لأنه يكسر العميل أيضًا
الكود المصدري مثل العديد من وحدات Micro ORM هي مجرد طرق امتداد عبر واجهات 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"));

تتمثل إحدى ميزات القابلية للتوسعة من استخدام طرق الامتداد في أن أدوات ORM هذه "مفتوحة النهاية" ويمكن للعملاء توسيع ORM باستخدام واجهات برمجة التطبيقات من الدرجة الأولى الخاصة بهم عن طريق إضافة طرق الامتداد في مشاريعهم الخاصة - وهذه أيضًا معطلة.

من الواضح أن أي كود مصدر يمر عبر IDbConnection حوله ممنوع الآن أيضًا من العمل على CoreCLR.

على سبيل المثال ، يتم استخدام واجهات ADO.NET الأساسية

ملخص

أنا شخصياً مندهش من أنه سيكون هناك مستقبل في .NET بدون هذه الواجهات.
تكون الواجهات حسب التصميم مخصصة لغرض معين للسماح بالتطبيقات المتعددة و ADO.NET واحدة
من أهم "نماذج الموفر المفتوح" في .NET. ليس لدي أي فكرة عن الأولويات التي تسببت في إزالة هذه الواجهات ، ولكن يجب إعطاء أولوية أعلى بكثير لقواعد كود .NET الضخمة الحالية التي تعتمد على هذه الواجهات جنبًا إلى جنب مع نظام EF .NET البيئي البديل. يتسبب هذا في حدوث اضطراب كبير وهو عائق رئيسي مطلوب لدعم كل من الأنظمة الأساسية الحالية .NET 4.x و CoreCLR ، مما يفرض قدرًا غير ضئيل من التعقيد الإضافي الذي يجب تطبيقه على جميع قواعد التعليمات البرمجية الحالية المتأثرة بهذا.

التصور الحالي هو إعادة تصميم ADO.NET/CoreCLR لتوفير دعم من الدرجة الأولى لـ EF و SQL Server مع تجاهل بقية النظام البيئي - قرارات كسر غير شفافة مثل هذه تذهب فقط لإعادة فرض هذه الصورة النمطية .

بصفتي عضوًا سابقًا في فريق .NET (أعمل الآن في Roslyn) ، فقد شاركت بشكل كبير في التصميم الأصلي للبيانات الجديدة المشتركة ، جنبًا إلى جنب مع فريقي SQL و Entity Framework. أنا لا أشارك فيه في الوقت الحالي ، لكن يمكنني إضافة بعض المعلومات الأساسية للمساعدة في تصحيح بعض العبارات التي أراها على Twitter وما فوق.

بدأ التصميم الحالي لـ System.Data.Common for .NET Core في ديسمبر 2012 ، قبل عامين تقريبًا من فتح المصدر.

الأهداف:

• صمم مساحة سطح حديثة لـ .NET Core ، والتي قللت من تكرار المفاهيم ( IDbConnection مقابل DbConnection ) ، الارتباكات ، الأخطاء ومشكلات الطبقات (فصل SqlClient من DataCommon ، فصل DataSet عن التجريدات الأساسية) من التصميم الأصلي من .NET 1.0. واحد يمكن انتقاؤه بسهولة ، سواء من قبل المستهلكين الحاليين والمطورين الجدد إلى .NET Framework.
• قم بتمكين الموفرين والمستهلكين من إنشاء ثنائي / مصدر واحد مقابل .NET Core ، ثم قم بتشغيل نفس البرنامج الثنائي على .NET Framework. لاحظ أن العكس لم يكن هدفاً ؛ القدرة على استخدام برنامج .NET Framework الثنائي / المصدر وتشغيله دون بعض التغييرات على .NET Core.

تصحيح بعض الأشياء المنتشرة حولها:

• الواجهات كما هي غير قابلة للإصدار. لا يمكننا إضافة أعضاء إلى الواجهات ، ويتطلب الاقتراح أعلاه المقدم من 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).

شيء أجد صعوبة في فهمه:

لا يمكننا إضافة أعضاء إلى واجهات

كيف لا يكون من المقبول إضافة أعضاء إلى واجهات CoreCLR حتى الآن ، فلا بأس من نسخهم بالكامل؟

يتطلب الاقتراح أعلاه المقدم من mythz عبر طرق الامتداد أن يشتق

الجزء المهم هو أن الواجهات موجودة وتسمح بتجميع التعليمات البرمجية المصدر التي تشير إليها.

إذا كنت لا ترغب في نسخ الواجهات ، فقم بمدها جيدًا ، فقط قم باستعادة الواجهات كما كانت قبل أن يتم اقتلاعها وتخفيف العبء المفروض الآن على كل مكتبة أخرى تستخدمها. أعني أن هذه الواجهات الأساسية لم تتقادم أبدًا مع عدم توفير تحذير أو مسار ترحيل. ومع ذلك ، فإننا نعاقب على اعتماد واجهة برمجة تطبيقات منشورة ومعروفة ومستقرة كجزء لا يتجزأ من مكتباتنا؟

إنه منفذ بسيط للغاية للانتقال إلى الفئات الأساسية.

يجب إضافة هذا إلى كل ملف مصدر يشير إلى واجهات ADO.NET ، ويجبر العملاء على نقل التعليمات البرمجية الخاصة بهم برموز إنشاء مخصصة.

لا يبدو أن هناك نفس الاهتمام بالتوافق مع الإصدارات السابقة هنا ، ولكن كسر العملاء الحاليين عمدًا في إصدار مستقبلي ليس مجرد خيار (أنا مندهش من أنه تم اعتباره مع حصة سوقية أكبر بكثير لـ ADO .NET). لا يمكننا كسر عملاء الإصدار 4.x الحاليين ، ومع ذلك يُطلب منا دعم CoreCLR - فأين يترك ذلك مكتبات 4.x الحالية التي ترغب في الحفاظ على التوافق مع الإصدارات السابقة ودعم CoreCLR أيضًا؟ هل يجب علينا نسخ المستندات / الأمثلة أيضًا؟

كيف لا يكون من المقبول إضافة أعضاء إلى واجهات CoreCLR حتى الآن ، فلا بأس من نسخهم بالكامل؟

يجب أن تكون مساحة السطح في .NET Core متوافقة بشكل ثنائي مع .NET Framework لتمكين الأطراف الأولى والأطراف الثالثة من البناء على .NET Core وتشغيل قابلية النقل دون تغييرات على .NET Framework. إن إضافة أعضاء إلى واجهات تنتهك ذلك ، حيث سيفشل مستهلكو هؤلاء الأعضاء عند تشغيلهم باستخدام .NET Framework.

أنا لا أطالب بإزالة أو إضافة هذه الواجهات ، أردت فقط إضافة بعض المعلومات الأساسية عن سبب انتهاء التصميم في مكانه. سأسمح للمالكين الحاليين بما في ذلك YoungGah و @ saurabh500 بمعالجة ذلك.

فقط لتلخيص الخيط ، السبب الذي يجعلك تعتقد أن Microsoft يجب أن تقوم بنقل هذه الواجهات ، هو تمكين النظام البيئي من الانتقال بسهولة إلى .NET Core ، مع الحفاظ على تطبيقات .NET Framework الخاصة بهم؟

هو تمكين النظام البيئي من النقل بسهولة إلى .NET Core ، مع الحفاظ على تطبيقات .NET Framework الخاصة بهم؟

نعم فعلا.

فقط لتلخيص الخيط ، السبب الذي يجعلك تعتقد أن Microsoft يجب أن تقوم بنقل هذه الواجهات ، هو تمكين النظام البيئي من الانتقال بسهولة إلى .NET Core ، مع الحفاظ على تطبيقات .NET Framework الخاصة بهم؟

نعم فعلا. يتم الآن كسر واجهات برمجة التطبيقات الخارجية إذا قمت بنقل قاعدة الكود الخاصة بي (LLBLGen Pro) إلى corefx: ثم يتعين عليّ كشف 2 apis أو كسر قاعدة الشفرة الحالية لجميع المستخدمين.

قد يكون من الجيد لك أيها الناس كسر الأشياء الخاصة بنا لأنك لا تشعر بالألم ، نحن نشعر بذلك. هذا ليس جيدًا من قبلي: يجب أن أعيش مع قاعدة رمز ذبح وأن أحافظ على واجهتي API تقومان بنفس الشيء ، أو كسر كود المستخدمين لأنك اعتقدت أن ذلك جيد.

أنا أيضًا لا أفهم سبب عدم إصدار الواجهات ، إنها مجرد واجهة ، مثل فئة بها واجهة أيضًا. يمكن لـ CoreFX إضافة طرق غير متزامنة إلى الواجهات.

يجب أن تكون مساحة السطح في .NET Core متوافقة بشكل ثنائي مع .NET Framework لتمكين الأطراف الأولى والأطراف الثالثة من البناء على .NET Core وتشغيل قابلية النقل دون تغييرات على .NET Framework. إن إضافة أعضاء إلى واجهات تنتهك ذلك ، حيث سيفشل مستهلكو هؤلاء الأعضاء عند تشغيلهم باستخدام .NET Framework.

حل سهل: أضف الواجهات كما هي الآن. وبمجرد أن تدرك جميعًا أن هذه القاعدة المذكورة أعلاه هي في الواقع غبية إلى حد ما ، يمكنك إضافة الأساليب التي تحتاجها لإضافتها إلى الواجهات منذ فترة طويلة إلى الواجهات والمضي قدمًا.

أنا أعمل مع برنامج MS لفترة كافية بحيث تكون القواعد مثل تلك المذكورة أعلاه رائعة على الورق ولكن من الناحية العملية يتم كسرها في الثانية التي يحتاجها فريق MS المهم لكسرها. إذا كنت "منفتحًا" و "مختلفًا" كما تقول في CoreFX marketing / pr hoopla ، أظهر ذلك. كل ما أراه فيما يتعلق بالنظام System.Data و CoreFX هو "ما تحتاجه MS هو القيام به ، وما يحتاجه الآخرون هو في حالة تأخر أو يتم تجاهله".

شيء آخر نسيت أن أذكره: ذكر فاولر أمس على تويتر أنك بحاجة إلى كل شخص لنقل أشياءه. يجب أن أدفع مقابل نقل 500K LoC codebase إلى CoreFX بنفسي ، الأمر يستغرق وقتًا وجهدًا وسيأخذ وقتًا طويلاً للحصول على ميزات أخرى. الاحتكاك الإضافي المصطنع تمامًا (إنه نظام أساسي جديد! كيف يمكن أن تكون هناك قواعد تقييدية؟) حقًا لا يساعد على الإطلاق: فهو يضيف تكاليف صيانة إضافية ، ويستغرق وقتًا إضافيًا لنقل الكود واختباره ويمنح عبئًا إضافيًا على مستخدمينا.

يبدو أن كل ما هو خارج نطاقك ، وليس ما يقلقك. لكنك نسيت شيئًا واحدًا: ماذا _if_ لم نقم بنقل الكود الخاص بنا ومع المزيد من الأشخاص؟ أنا على استعداد لاستثمار الوقت وبالتالي أموالي الخاصة لنقل قاعدة الرموز الكبيرة الخاصة بي إلى إطار العمل الجديد اللامع الخاص بك ، ولكن آسف لقول ذلك ، كلما واجهت مشكلة ، أواجه قيودًا وقواعد غريبة ومناقشات لا نهاية لها تنتهي بصمت . آيو: أشعر أنني تركت وحدي بينما في نفس الوقت يبدو أنك تريد بشدة منا أن نحب إطارك اللامع الجديد.

كما قلت منذ وقت طويل : قم ببيع هذا الإطار ، هذا CoreFX الجديد. حسنًا ، الحفاظ على الاحتكاك وإدخال الكثير من الجبن المنقول والمنزول لا يخلق حافزًا كبيرًا لاستثمار قدر كبير من الوقت (والمال) في هذا.

فقط سنتان.

FransBouma من فضلك دعنا نحاول أن نجعل هذه المحادثة محترفة ومنتجة ومركزة على الحقائق.

أنا لا أجادل مع أو ضد إضافة الواجهات. ومع ذلك ، لا تتوافق إضافة أساليب إلى الواجهات. دعنا نتصفح هذا:

1) أضف IDbConnection.OpenAsync إلى .NET Core
2) أي شخص يستدعي هذه الطريقة ، سيفشل الآن في العمل على .NET Framework (كسر مبدأ / هدف أساسي أشرت إليه أعلاه). هذا أيضًا يكسر مصمم XAML وبعض ميزات VS الأخرى التي تعتمد على هذه الحقيقة بالذات.
3) لتحديث .NET Framework ، نقوم بشحن إصدار جديد من .NET Framework "4.7" مع IDbConnection.OpenAsync
4) كل نوع منفرد قام بتطبيق IDbConnection قبل إضافة هذه الطريقة يفشل الآن في التحميل على .NET Framework "4.7"

هذا هو السبب في أننا لا نستطيع إضافة أساليب إلى الواجهات.

إذا ظللت أشعر بالإحباط من الطريقة التي تسير بها الأمور فيما يتعلق بإبلاغ نفسي بالمشكلات ، فلن تعرفوا جميعًا عنها وتعتقدون أن كل شيء هو الورود وأقواس قزح. إذا كان هذا يبدو غير احترافي ، فليكن ذلك ، فأنا لا أهتم بما إذا كان مرض التصلب العصبي المتعدد يعتقد أنني محترف أم لا.

بعد قولي هذا: أنا لست متزوجًا من الواجهات ، لذا إذا اختفت ، فإن حقيقة أنه من الآن فصاعدًا هناك فصول ولا توجد واجهات للعمل بها نظريًا لن تجعلني دبًا حزينًا: ما يجب فعله يمكن يتم إجراؤه نظريًا من خلال الفئات الأساسية أيضًا ، اليوم ، حيث يلعب جميع مزودي ADO.NET الرئيسيين اليوم بشكل جيد ويستمدون من الفئات الأساسية (لم يكن هذا هو الحال في IIRC السابق مع تطبيق ODP.NET للواجهة ولكن ليس المشتقة من الفئة الأساسية). هذا أيضًا هو السبب الذي جعلني في البداية أعلاه في هذا الموضوع لا أعتقد حقًا أن إزالتها كانت مشكلة كبيرة. منذ ذلك الحين كان لدي بعض الوقت للتفكير في الأمر وأعتقد أنه _هو _ مشكلة كبيرة.

نحن لا نعيش في فراغ على كوكب المريخ ، وتواجه البرمجيات الوسيطة / أطر العمل في أسفل المكدس مشكلة الآن: يرغب مستخدمو إصدارات .NET الكاملة الحالية من هذه الأطر في الاستمرار في استخدامها على CoreFX كما يعرفون هذه الأطر. ومع ذلك ، فإن نقلها إلى CoreFX يعد بمثابة PITA كبير ، بسبب عدد لا يحصى من الأسباب ، أحدها غالبًا ما يستخدم واجهات معروضة في واجهات برمجة التطبيقات العامة غير الموجودة على CoreFX (والسبب في هذا الموضوع).

لهذا السبب وحده أود رؤية الواجهات مرة أخرى. بالنسبة لي شخصيًا ليس لأسباب فنية (على سبيل المثال ، يحتاج غير المتزامن إلى فئات أساسية ، إنها فوضى بالفعل). وأنا أعلم أنها تفتقر إلى وسائل معينة، ولكن هذا مشكلتك، ليس من الألغام. إزالتها يجعل هذا مشكلتي و(مقتبسا الآن) استجابة MS على ذلك هو: "لا يمكن القيام به" رمي يديك. لكن ليس لدي هذه الرفاهية. لقد خلقت هذه الفوضى ، وقمت بحلها. تريد مني أن أنقل الكود الخاص بي ، لاستثمار الكثير من الوقت والمال (وهو ما يجب أن أدفعه لنفسي) لدعم إطار العمل الجديد الخاص بك ، فلماذا تقوم بعد ذلك بعمل مشكلتك _ مشكلتك _ my_؟

بالنظر إلى سيناريو الخطوات الأربع الخاص بك: إضافة طرق إلى الواجهات ليست مشكلة إذا رأيت CoreFX كإطار عمل منفصل. أليس هذا هو الحال على أي حال؟ إنه نفس الشيء كما هو الحال مع Compact Framework طوال تلك السنوات الماضية (والذي قمت بنقل إطار العمل الخاص بي إليه ، وتعلمت بعض الدروس الصعبة ، ثم أخبرني أن النقل إلى CoreFX لن يكون بسيطًا وسريعًا وسهلاً مع الاحتفاظ بقاعدتي رمز لن أيضًا): نبدأ بواجهة برمجة تطبيقات واحدة ، ثم نسي شخص ما شيئًا ما أو أن بعض الفريق داخل MS يحتاج إلى شيء ما ، و فيولا تغيير فاصل فقط سيتم تشغيل عدد قليل من مطوري المكدس منخفض المستوى وما إلى ذلك وسيتم تقسيم الطريقين.

(على سبيل المثال: نسي الإطار المضغوط "SerializableAttribute". أضافوا ذلك باستخدام سمة وهمية لا تفعل شيئًا في إصدار لاحق ، لكن ذلك كسر الكود الذي كان متوقعًا لعدم وجوده والذي حدد خاصيته)

ومع ذلك ، فإن تقسيم الطرق أمر مفهوم: محاولة الحفاظ على توافق الأشياء أمر مقيد للغاية. أتوقع هنا الآن أنه سيتم كسر هذه القاعدة في المستقبل.

تعتبر رؤية الأشياء على أنها "متوافقة" أمرًا مهمًا ليس فقط على مستوى توقيع واجهة برمجة التطبيقات ، ولكن أيضًا على مستوى سلوك _ API. إن الثقة في أن هذين الاثنين سيكونان متشابهين تمامًا (CoreFX و .NET Full) في سلوك واجهة برمجة التطبيقات أمر محفوف بالمخاطر للغاية: سيتعين على مطور إطار العمل اختبار نفس الوظيفة على CoreFX وعلى .NET full ، لا توجد طريقة للاختبار على CoreFX وحدها. يكفي أن نفترض أن الكود يعمل بنسبة 100٪ بنفس الطريقة على .NET full في المستقبل: لأنه كيف يمكنك ضمان ذلك؟ تلامس مكدس المكالمات البالغ 20 مكالمة عميقة في CoreFX الكثير من التعليمات البرمجية الأخرى غير الموجودة على .NET full ، وتفاصيل صغيرة هنا وهناك وتغيرت الأشياء.

النقطة في كل هذا هي: إنه إطار عمل منفصل: يمكن توقع أن تكون التعليمات البرمجية المجمعة مقابل CoreFX مختلفة عن التعليمات البرمجية المجمعة مقابل .NET full.

هناك حالتان:

1) إطار عمل له قاعدة رمز يتم تجميع 100٪ منها على CoreFX. هذا يعطي dll الذي يمكن تشغيله على .NET كامل
2) إطار عمل له قاعدة رمز والتي يتم تجميع 70٪ منها على CoreFX و 100٪ على .NET كامل. هذا يعطي 2 dlls: واحد لـ CoreFX والآخر لـ .NET ممتلئ. من السخف تشغيل إصدار CoreFX على .NET بالكامل ، حيث يفقد المرء 30٪ من الوظائف.

في حالة 1) أفهم وجهة نظرك. في حالة 2) (وهذا هو الحال بالنسبة لجميع أطر عمل الاستهداف الكاملة الحالية لـ .NET ، من بينها _all_ ORMs التابعة لجهات خارجية) ، فإن وجهة نظرك لا معنى لها حقًا ، حيث سيتعين عليهم العمل مع dlls على أي حال: 2 من قواعد البرمجة الفعالة التي يجب أن يتم الاحتفاظ بها بشكل منفصل واختبارها بشكل منفصل وترحيلها إلى الإصدارات الجديدة الخاصة بها بشكل منفصل. خاصة إذا حصلت CoreFX على ميزات جديدة ليست جزءًا من .NET full (وهو ما سيكون عليه الحال) حتى الآن. (راجع للشغل: إذا قمت بإضافة DbDataReader.GetSchemaTable () إلى CoreFX الذي يقوم بإرجاع بنية بيانات مختلفة عن DataTable ، لأن MS ترفض منفذ ذلك ، فإن التعليمات البرمجية باستخدام DbDataReader.GetSchemaTable على CoreFX ستتعطل على .NET بالكامل أيضًا. إذا قمت بتسميتها بشكل مختلف سوف تتعطل كما أن الطريقة غير موجودة.

لعدم وجود واجهات على CoreFX يجعل وضع إطار العمل في الحالة 2) ثابتًا: لا يمكن أن يتحركوا ليصبحوا إطار عمل يتناسب مع 1) لأن API الخاص بهم على سبيل المثال يعرض الواجهات.

تعيد Microsoft كتابة الأشياء الخاصة بها بحيث تصبح أطر عملها في الوضع 1) أمرًا رائعًا ، ولكن ليس لدينا ميزانية تبلغ مليون دولار ، وأكثر من 15 شخصًا في وقت تشغيل ORM وآلة علاقات عامة كبيرة من جانبنا والتي ستعمل على تخفيف تجاعيد كسر كل تطبيق هناك. لذلك نحن إما عالقون في 2) أو نحتاج إلى القليل من المساعدة من MS للانتقال إلى 1).

هذا ما هو على المحك هنا. قلت على تويتر "أخبرنا بما تحتاجه". نحن فعلنا. مرارا وتكرارا. خاصة فيما يتعلق System.Data لا يوجد اتصال. لا شيئ. لا توجد خطط مستقبلية ، ولا نقاش حول ما يجب القيام به ، فقط طرق مسدودة وأحيانًا إذا تدخل شخص في مرض التصلب العصبي المتعدد ، فهو شخص ليس لديه مصلحة حقيقية في هذا الأمر. أنا أقدر الوقت الذي قضيته في هذا الأمر ، فكلما حصلنا على معلومات أساسية أكثر ، كان ذلك أفضل ، ولكن في الوقت نفسه ، يبدو الأمر أشبه بالتحدث إلى زميل في العمل حول هذا: لن يتم حل المشكلة لأن الشخص (الأشخاص) المسؤول غائبون وليسوا المشاركة في المناقشة.

إذا كان هذا يجعلني أبدو محبطًا والعياذ بالله "غير محترف" ، فليكن.

شكرا على الإنصات. بالمناسبة ، ليس لدي أي أوهام في النظام البيانات: ستكون بمثابة حطام لواجهة برمجة التطبيقات (API) لنقل التعليمات البرمجية إلى ، ولأنه لا يوجد اتصال من الأشخاص المسؤولين مع المطورين الذين يكتبون أطر عمل رئيسية فوق واجهة برمجة التطبيقات الخاصة بهم ، فهناك القليل من الأمل في الأشياء. سوف يتغير. ليس خطأك ، davkean ، لا شيء شخصي.

لا بد لي من ترديد الإحباطات المذكورة أعلاه بشأن الافتقار إلى التواصل. نحن بحاجة إلى إدخالات مجمعة ومعلومات المخطط أيضًا. لم يكن هناك أي تقدم أو اتصال خلال أكثر من شهر (انظر dotnet / وقت التشغيل # 15269 و dotnet / وقت التشغيل # 14302) لهذه الوظائف الأساسية المفقودة (في كلا الاتجاهين). ومع ذلك ، فإن Microsoft تصنف الكود الحالي بأنه "مرشح للإصدار" ، وهو في حد ذاته رسالة "إنه جيد بما فيه الكفاية". ليست كذلك. هناك أشياء أساسية مفقودة تحتاج إلى إضافتها ، وإذا اتبعت هذه الخيوط ، فيجب أن تكون في الإصدار الأول لأسباب تتعلق

انظر إلى آخر تحديث على dotnet / وقت التشغيل # 14302 ("لماذا DataTable / View / Set غير موجود؟") ، إنه منذ 22 يومًا يسأل:

إذاً System.Data.Common هي ميزة مكتملة الآن لـ V1 من CoreCLR؟

نعم ، يمكن أن يبدو الإحباط غير مهني. نبرة وسياق النص سيئة ودائما ، ولكن هذا ما نحن مقيدون به هنا. أعتقد أن الجميع يحاول أن يكون منتجًا هنا ، لكننا نحصل على قدر كبير من المماطلة من جانب CoreFX بشأن التقدم الفعلي في منطقة System.Data وهذا يعني ، أن تكون فظًا ، يثير غضب كلاهما كمؤلف مكتبة ومستخدم لهذه البتات.

نحن بحاجة إلى هذه الأجزاء الوظيفية الأساسية ، أو الواجهات أم لا - فأنا لست مضطربًا للواجهات وقد نقلنا Dapper بدونها. لكن نقص DataTable ، ومعلومات مخطط النتائج ، والإدراج المجمع ، وغير مقبول في "الإصدار المُرشح". مايكروسوفت هي التي تزيد من الإحباط عند تصنيف الكود الحالي على أنه RC عندما يكون هناك اتفاق عالمي تقريبًا على أنه ليس جاهزًا للإصدار. نعم ، إنها مجرد تسمية ، لكنها تسمية غير صحيحة وتزيد بشكل كبير من مستوى الإلحاح لأنها تستند إلى جدول تعسفي (كان يجب أن يتغير ليعكس الواقع). لا أعتقد أن أي شخص في هذا الموضوع مسؤول عن هذا الجدول الزمني ، ولكن من الجدير ذكره كعامل رئيسي في الإحباط _المستوى_.

دعنا نعود إلى مشكلة الجذر. نحن بحاجة إلى هذه القطع ، والعديد من المستخدمين لدينا يفعلون ذلك. لذلك دعونا نصلحها.

دعونا لا ننسى NHibernate مع 1 مليون + تنزيل :

| IDbConnection | IDbCommand | IDataReader |
| --- | --- | --- |
| 59 | 181 | 132 |

التصور الحالي هو إعادة تصميم ADO.NET/CoreCLR لتوفير دعم من الدرجة الأولى لـ EF و SQL Server مع تجاهل بقية النظام البيئي - قرارات كسر غير شفافة مثل هذه تذهب فقط لإعادة فرض هذه الصورة النمطية .

يتم تعزيز هذا التصور من خلال أشياء مثل هذا: https://github.com/dotnet/corefx/issues/4646

بقدر ما أستطيع أن أقول ، لا توجد طريقة لتنفيذ واجهة برمجة التطبيقات هذه بأي طريقة مفيدة خارج تجميع SqlClient.

أنا موافق حاليًا على الاختبار بدون واجهات. لكن بصراحة لا أفهم المنطق فيما يتعلق بإصدار الواجهة والتوافق.

أليست فكرة NET Core هي أنه إطار عمل جديد بدون عبء التوافق ، وأنه مدمج مع تطبيقك ، لذا لا يتعين عليك التعامل مع مشكلات من هذا القبيل؟ الموفر غير متوافق بالفعل مع تلك الموجودة في .NET بسبب نقص أشياء مثل المخططات وجداول البيانات ، فما الذي قد يكسر التوافق معه؟ إذا تغيرت الواجهة ، فقم فقط بالتجميع مقابل الإصدار الجديد وتجميعه مع تطبيقك.

يبدو أن معظم الأعذار للتصميم هي مجرد مخاوف من الإطار القديم التي لا تنطبق على الإطار الجديد. على أي حال ، دعنا نرى كيف اتضح أنه عمليًا.

بالنسبة لأولئك الذين ينوون دعم أطر عمل متعددة ، واستهدفوا الواجهات تاريخيًا ... أريد فقط مشاركة كومة من القبيح التي يستخدمها Dapper ؛ أنا لا أقول أن هذا _جيد_ ، لكنه يكفي لجعله مجمعًا. بالطبع ، يتم نسخه في كومة ضخمة من الملفات ... أنا أشارك هذا بشكل أساسي للتأكيد على تأثير آخر:

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

لا يمكننا إضافة أعضاء إلى واجهات

صحيح ، وهذه ميزة _جيدة_ للواجهات. يُعد تفضيل الفئات الأساسية المجردة الطريقة الأكثر أمانًا لمساعدة إنتروبيا API على طول ، بدلاً من محاربتها.

بينما لا يتعين عليك اتباع مبادئ OOD ، فإنني أقترح عليك القيام بذلك ، عند إنشاء واجهات برمجة تطبيقات OO. باختصار ، ينص مبدأ فصل الواجهة (ISP) على أنه لا يجب إجبار أي عميل على الاعتماد على الأساليب التي لا يستخدمها.

إذا أضفت طرقًا جديدة إلى عملية تجريد موجودة ، فإنك تنتهك تلقائيًا ISP.

يمكنك أن تقرر أنك "لست مضطرًا للالتزام بـ SOLID" لأنك Microsoft ، وأنت تعمل مع BCL ، لذلك "القواعد العادية لا تنطبق" (وليس الاقتباسات الفعلية ؛ فقط إعادة صياغة العادي الحجج المضادة).

بعد أن حافظت على عدد من المشاريع مفتوحة المصدر لمدة 6-7 سنوات ، من الأفضل حسب تجربتي إبقاء الواجهات صغيرة. إذا كنت بحاجة إلى إضافة إمكانيات جديدة إلى فكرة مجردة ، فقم بتقديم واجهة جديدة.

• " برنامج إلى واجهة ، وليس تطبيق. "
• " تفضل تكوين الكائن على وراثة الطبقة. "

إذا كان هناك upvotes هنا، كنت قد upvotedploeh الصورة تعليق +1000

تعليق ثاقب من

FransBouma ، سنضيف وظيفة الاستبدال لـ DbDataReader.GetSchemaTable () بطريقة لن تكسر الإطار الكامل.
NickCraver ، SqlBulkCopy في خطتنا المستقبلية ونحن نعمل على المخطط. نحن بطيئون في إحراز تقدم في المخطط لأننا نحتاج أيضًا إلى إحراز تقدم معقول في جعل مكدسنا يعمل على x-platform.
mythz ، شكرًا على تقديم الأمثلة والأرقام وتقييم تأثير العميل. سوف نقوم بمراجعتها.

YoungGah يرجى تحديث المشكلات المتعلقة بالمعلومات حتى تظل هذه المشكلات محدثة ، على سبيل المثال https://github.com/dotnet/corefx/issues/1039 ، وإلا فإن المعلومات المتناثرة مبعثرة في كل مكان. من الجيد أنك ستضيف GetSchemaTable (وما يعادله من DbConnection ، لا تنسى ذلك!) ، ولكن من الصعب جدًا الحصول على أي معلومات حول ما سيحدث ومتى. هل هناك خطة ماذا سيضاف ومتى؟ كل ما علينا أن نواصله الآن هو تلميح إلى أنه قد يتم إضافة شيء ما في "المستقبل". هذا ليس رائعًا حقًا للتخطيط لمنفذ قاعدة رمز ، لأكون صادقًا.

FransBouma ، نعم ، سأقوم بتحديث المواضيع الأخرى أيضًا. بالنسبة لطلبك للحصول على مزيد من المعلومات حول ماذا ومتى سيكون متاحًا ، فأنا أفهم تمامًا سبب حاجتك إليه يا رفاق. سأقوم بنشر القائمة التي ستشير إلى ما إذا كانت الميزة / الوظيفة ستكون متاحة في الإصدار 1 ، أو إزالتها عن قصد ، أو ستتوفر بعد الإصدار 1 ، أو أن تصميم التوفر المستقبلي معلق. سأحاول نشره خلال الأسبوعين المقبلين. بالنسبة إلى الحصول على وظيفة المخطط على وظيفة DbDataReader و DbConnection ، فإن خطتنا هي جعلها متاحة لإصدار rc2. إذا تغيرت الخطة لبعض الأسباب غير المتوقعة ، فسنقوم بتحديث المجتمع.

ماذا يحدث هنا ، وللرجوع إليه في المستقبلYoungGah ؛ يعتمد IDataReader على DataTable ، والذي له تبعية على DataSet (التي نعتبرها طبقة منفصلة - لأنها سياسة ثقيلة ، على عكس هذه الأنواع الخالية من السياسات) ، لذلك هناك بعض أعمال التصميم هنا لكسر ذلك إذا كانت هذه الواجهات موجودة على الإطلاق أعاد.

سأضع تصويتًا آخر هنا davkean على الفصل بالإضافة إلى معالجة الإصدار.

لماذا لا يكون لديك فقط واجهة جديدة ترث القديمة. عفا عليها الزمن القديم. أزل القديم في المستقبل. على الأقل بعد ذلك يمكنك تمديده وعدم كسر الاستخدامات الحالية.

أو واجهات متعددة أصغر. أنا فقط حصلت على تعليق ploehs.

لا أفهم هذه الحاجة إلى التوافق التام مع .NET الأصلي. لا يوجد شيء يمكن كسره هنا ، هذا إطار عمل جديد وفرصة مثالية لكسر الروابط مع الكود القديم وتطبيق التغييرات المطلوبة لفترة طويلة ولكنها ستضر في الإطار الأصلي.

عندما اقترحت إعادة الواجهات ، لم أكن أفكر في إحضار واجهات 1.1 الأصلية ، ولكن واجهات محدثة مع التصميم الجديد. يمكن أن يكون هناك المزيد منهم ، كما قال ploeh .

واجهات نعم ، دعم قديم إن أمكن ، لكن لا ينبغي أن يكون أولوية في هذه المرحلة.

إعادة الفتح نظرًا لوجود الكثير من الاهتمام بهذا الموضوع.

لا يوجد شيء يمكن كسره هنا ، هذا إطار عمل جديد وفرصة مثالية لكسر الروابط مع الكود القديم وتطبيق التغييرات المطلوبة لفترة طويلة ولكنها ستضر في الإطار الأصلي.

إذن ، فإن الفرصة المثالية للتخلص من الواجهات الأصلية المصممة بشكل سيئ والتوحيد القياسي في الفئات الأساسية مثل ADO.NET تفعل بالفعل؟ :وجه القزم:

على محمل الجد ، لديك خيار بين واجهة برمجة تطبيقات نظيفة أو التوافق مع الإصدارات السابقة. إختر واحدة. لا أرى طريقة للحصول على كعكتك وأكلها أيضًا.

JamesNK لكن هذا بالضبط هو الهدف. التوافق مع الإصدارات السابقة غير مطلوب ، فترة.

أنت مزاح ، لكن واجهة برمجة التطبيقات API ذات التصميم السيئ مع الواجهات كانت سيئة لأنها كانت مصممة بشكل سيء ، وليس لأنها كانت واجهات. =) ليس الأمر وكأن الواجهات لا تُستخدم مطلقًا في كل مكان في NET أو أن هذا شيء جديد. ما عليك سوى تصميم الشيء بشكل صحيح هذه المرة والمضي قدمًا.

تعد ADO.NET واحدة من أكثر أجزاء التعليمات البرمجية استقرارًا في جميع برامج .NET. كان لديه اثنين أو ثلاثة تغييرات خطيرة في 15 عاما. إنها واجهة برمجة التطبيقات المثالية للاستقرار في الواجهة وجعلها أبسط للجميع.

كملاحظة ، يعد هذا الموضوع هنا أحد أكثر المشكلات التي تم التعليق عليها أيضًا ، وكان له نفس المناقشة الطويلة حول الواجهات مقابل الطرق الافتراضية وقابلية الاختبار والأشياء.

nvivo يجب أن أعترف ، أنا في حيرة من

لماذا لا يمكننا الحصول على واجهات أصلية للتوافق مع الإصدارات السابقة والمضي قدمًا في كل ما تختاره (إما فئات مجردة أو واجهات صغيرة)؟ يمكن أن تكون الواجهات الأصلية أعلى المكدس الجديد وتوفر التوافق مع الإصدارات السابقة. يمكن أن يكون هذا الجزء اختياريًا أيضًا.
هذا من شأنه أن يجعل النقل سهلاً ولا يزال يسمح بطريقة جديدة.

تضمين التغريدة

لا يمكنني الرد على كل من علق هنا. اقترحت استخدام واجهات مثل API لـ ADO.NET ، محدثًا إلى API الحالي الجديد. لم أطلب إحضار الواجهات الأصلية وجميع المشاكل التي واجهتها. كان الغرض هو الحصول على واجهة برمجة تطبيقات محددة وأنظف وتسهيل السخرية منها واختبار الكود الذي يعتمد عليها ، ومعظمها مكتبات تجريد البيانات وليس رمز المستخدم.

تعتبر الواجهات أفضل في وصف واجهات برمجة التطبيقات كما قال ploeh بحكمة ، ومن السهل جدًا السخرية منها. التصميم الحالي سيئ للغاية في السخرية ، ويتطلب منك تنفيذ الموفر بالكامل تقريبًا كمكتبة لإجراء اختبارات بسيطة. إذا لم يكن ذلك مهمًا للجميع ، يمكنني أن أفهم. لكنني بالتأكيد لا أوافق على أنه قابل للاختبار بما فيه الكفاية اليوم. اختبار ما إذا تم استدعاء الطريقة A بالمعامل X عن طريق التحقق مما إذا كانت الطريقة B تسمى C مع المعلمات X ، Y ، Z ليست مثالية.

الآن ، فقط لنرى كيف تقوم الفصول بالفعل بإنشاء تصميم سيء:

• لماذا تمتلك DbCommand خاصية DesignTimeVisible ؟ هل يدعم وقت التصميم مطلبًا لتعريف الاتصال على أنه اتصال؟
• لماذا يوجد حدث لإخطار تغييرات الحالة ولكن لا يتم إخطار أشياء أخرى مثل تنفيذ الأوامر أو بدء المعاملات؟ هل يعد الإشعار مطلبًا لوجود اتصالات أو شيء يسهل إنشاء واجهات مستخدم؟
• هل ConnectionStringBuilder متطلبًا لوجود موفر؟ أو أكثر من شيء لطيف لجعل معالجات VS تعمل خارج منطقة الجزاء؟
• لماذا يحدد DbDataReader طرق Get لبعض الأنواع الأساسية ولكنه لا يضيف لأنواع أخرى مثل GetByteArray() و GetDateTimeOffset() ؟ وهل استرجاع TextReader مطلوب حتى إذا كان من الممكن القيام بذلك في الخارج باستخدام سلاسل أو تدفقات؟ إذا كانت هذه واجهة ، فهل ستتم إضافة مثل هذه الأساليب إلى واجهة برمجة التطبيقات أو إنشاؤها كطرق امتداد أو مساعدين في الفئات الملموسة (مثل عائلة GetSql* في SqlDataReader)؟

هذه كلها أسئلة بلاغية. أنا متأكد من أن كل منهم لديه إجابات مقنعة وأن الأمور قد تم أخذها في الاعتبار. النقطة المهمة هي أن التصميم الحالي من الواضح أنه ليس شيئًا تم التفكير فيه على أنه تعريف API ، وهو أمر من المحتمل أن يحظى بمزيد من الاهتمام مع الواجهات.

بصراحة ، من الخارج ، يبدو أن مناقشة التصميم كانت كما يلي:

• دعنا نحتفظ بهذه الأحداث هنا لأنه من السهل على المعالجات في الاستوديو المرئي العمل خارج الصندوق
• دعنا نزيل طرق استرجاع المخطط لأن لدينا EF وهذا ما يجب أن يستخدمه كل شخص في العالم ، نقطة.
• دعنا نحافظ على طرق الراحة هذه لأنها مدعومة منذ .NET 1.1 ولا يمكننا كسر التوافق أبدًا!
• دعنا نزيل جداول البيانات ومجموعات البيانات ونجعل كل شخص يأتي من .NET 1.1 يغير قاعدة بياناته بالكامل على أي حال!
• دعونا نبني نموذج مزود جديد يركز على الحوسبة السحابية ، والمجتمع ، والمصدر المفتوح وتطبيقات الغد ...
• ... ودعنا نبني هذا النموذج بناءً على احتياجات الأمس باستخدام SqlClient كحالة اختبار _sole_!
• لنقم ببناء إطار عمل جديد تمامًا سيتم دمجه مع كل تطبيق ، لذلك لا داعي للقلق بشأن تعطل التحديثات لتطبيقهم _ أبدًا مرة أخرى_!
• .. ثم دعونا نتخذ قرارات بعدم إضافة الواجهات لأن أي تغييرات قد تفسد تحديثاتها!

نعم ، هناك القليل من التشويش هناك وهذه المناقشة لن ​​تذهب إلى أي مكان =) ... لكن أردت فقط إخراج هذا من صدري. إنه عام 2015 ، كل شيء ينهار طوال الوقت ونحن معتادون عليه. سيكون هناك 20 تحديثًا لـ ASP.NET MVC في السنوات القادمة والتي ستتسبب في الكثير من التغييرات العاجلة عن تغييرات الواجهة في ADO.NET.

ما زلت أحب .NET وما تفعله به بشكل عام ، أنا متأكد من أنه من الاندفاع لإخراج .NET Core v1 في الوقت المناسب ولن يكون كل شيء مثاليًا. آمل فقط أن يتمكن المجتمع من المساعدة في توجيه هذا إلى اتجاهات أخرى مع مرور الوقت ولا تخشى كسر الأشياء أثناء تحركنا.

للمشرفين على إدارة ORM ، لماذا لا تفعل ذلك

ج #

إذا كان COREFX

System.Data {مساحة الاسم
IDbConnection الواجهة العامة {...}
}
""

واستخدام نمط المهايئ لالتفاف 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 المختلف ولكن نفسه الذي تقدمه). في الأساس ، هذا سيجعل الأمور أسوأ بعشر مرات.

هل يمكنك إعطاء مثال ملموس mgravell ؟ أستطيع أن أرى كيف يمكن أن ينكسر هذا إذا استخدمت Type.GetType("System.Data.IDbConnection, System.Data") ، أو ربما في سيناريوهات PCL.

إذا كان orm A يعرّف System.Data.IDbConnection ، ويعرف orm B
System.Data.IDbConnection ، فهناك الآن نوعان مختلفان تمامًا و
واجهات غير متوافقة لها نفس الاسم / مساحة الاسم ، والتعارض ، و
لا تعمل في الواقع من أي من مزودي قاعدة البيانات. لا يحل شيئًا ،
في الأساس. والأسوأ من ذلك: أنه يؤجر لواجهات برمجة التطبيقات غير القابلة للاستخدام حيث يتوقع شخص ما المرور
في SqlConnection أو NgpSqlConnection - ولا يعمل.

في الواقع ، يمكنك إنشاء حزمة شفرة مفتوحة المصدر لها ومشاركتها.

إذا لم يكن System.Data.Common ، فهذا يعني أن DbConnection لا ينفذه ، و: قد لا تهتم.

لن تحصل أبدًا على إجماع لكل مشرف موفر لـ ORM أو ADO .NET لتولي تبعية خارجية لجهة خارجية (يضمن إلى حد كبير عدم توفر SQL Server) ومكتبتين تعيدان تعريف واجهة BCL الأساسية لا يمكن استخدامها معًا. والأسوأ من ذلك بالنسبة لأطر العمل عالية المستوى (مثل ServiceStack) التي تشير إلى System. لن تتمكن واجهات البيانات في libs الأساسية (التي تحتاج الآن إلى تعريفها) من استخدام أي ORM لا يشير إلى نفس الواجهات - وهو ما لا - من شأنه أو ينبغي.

الطريقة الوحيدة التي يمكنك من خلالها التأكد من أن كل مكتبة تشير إلى نفس واجهات System.Data هي ما إذا كانت قد تمت استعادتها باستخدام الفئات الأساسية التي تنفذها - وهو ما لا زلت غير واضح بشأن الضرر الذي يسببه هذا.

mgravell ah تبعية متعدية ، لم

أنت تعلم أنني لا أفهم سبب كون هذه مشكلة ما لم تقرن بإحكام شفرتك برمز لا تملكه. حماية التعليمات البرمجية الخاصة بك من التبعيات! لفها واستخرجها بعيدًا. هناك العديد من الطرق للقيام بذلك وجعل الكود الخاص بك قابلاً للاختبار. كثير مذكور أعلاه. أنت تختبر التكامل مع البتات التي لا تملكها. هذه هي الطريقة التي يعمل بها. يجب ألا تسخر من كائنات BCL! إذا كنت كذلك ، فإن التصميم الخاص بك ليس جيدًا.

nvivo لقد

mythz هناك

أوافق على أنه ليس من الممكن لطرف ثالث توفير هذه الواجهات - يجب تنفيذها على التجريدات الأساسية حتى تكون مفيدة.

لقد فهمت أن هذه هي مشكلتك الأصلية ، لكن اتجاهها قد تحول الآن إلى موضوع حول إعادة واجهات عصر v1 لأسباب تتعلق بالتوافق. دعنا نركز على ذلك - إذا كنت ترغب في مناقشة إجراء تغييرات على مساحة السطح الحالية ، فيرجى تقديم مشكلات جديدة.

هذا لا معنى له على الإطلاق.

nvivo فهذا يعني أنك لست الشخص الذي لديه المشكلة على الرغم من تقديمها - وهذا واضح من خلال إغلاقها. تكمن المشكلة في استعادة واجهات System.Data لتخفيف عبء دعم النظام البيئي بأكمله الذي يعتمد عليها. يبدو أنك على ما يرام مع:

إنه عام 2015 ، كل شيء ينهار طوال الوقت ونحن معتادون عليه.

ولكن هذه ليست إستراتيجية مرضية لأولئك منا الذين يتعين عليهم دعم قواعد الكود الحالية وقواعد الكود الخاصة بعميلنا ، ولا ينبغي بالتأكيد أن تكون الإستراتيجية الافتراضية لأمناء مكتبات BCL التي تؤثر على كل .NET.

لكن هذه ليست استراتيجية مرضية لأولئك منا الذين يتعين عليهم دعم قواعد الكود الحالية

mythz هذا خارج السياق. ليس هذا ما قصدته. يجب على Evertybody هنا دعم قواعد التعليمات البرمجية الحالية ، وأشك في وجود أي وافد جديد إلى .NET في المناقشة.

المشكلة في ما تحولت إليه هذه المحادثة هي أنه ليس لها معنى كبير. NET Core هو إطار عمل جديد وليس ترقية. الكثير من .NET API الكامل الحالي غير موجود ولن يكون كذلك. لن يعمل التوافق مع الإصدارات السابقة بهذه الطريقة على أي حال.

nvivo هذا الشعور الدقيق هو سبب عدم انطباق هذه المشكلة عليك. إذا كنت تعتقد أن التوافق مع الإصدارات السابقة ليس مهمًا ، فأنت لم تحاول أبدًا دعم قاعدة تعليمات برمجية ذات مغزى تستهدف منصات متعددة - أنت أيضًا لا تتحدث نيابة عن فريق CoreCLR. لم يتم تطوير هذه المكتبات من البداية ، إذا قرأت أعلاه ستجد أن تشغيل مكتبات CoreCLR على .NET Framework الكامل هو الهدف الأساسي لمكتبات CoreCLR. يعد CoreCLR هدفًا آخر للنظام الأساسي الذي يعد نقل المكتبات الحالية أمرًا حيويًا لنجاحه ، وهو أمر يشجعه فريق .NET بشكل نشط والذي تعيقه هذه الواجهات المفقودة حاليًا.

مع كل هذا الحديث عن الواجهات ليست صديقة للإصدار ، يجعلني أفكر في كيفية تجنب لغة برمجة Go هذه المشكلة مع الواجهات الضمنية.

لقد طُلب مني أن أتوسع في ما أعنيه بالتجريدات _policy-free_.

في الأساس ، أعني من خلال عدم وجود سياسة أن التجريدات المشتركة System.Data.Common تحتوي على قواعد عمل تقريبًا صفرية - كل ما يفعلونه هو توفير شكل من واجهات برمجة التطبيقات التي يجب على موفر معين تنفيذها. هذا على عكس DataSet ، الذي يحتوي على الكثير من قواعد العمل والتعليمات البرمجية. تميل الأنواع الخالية من السياسة ، نظرًا لبنيتها ذاتها ، إلى الإصدار بشكل أقل تكرارًا من الأنواع التي تحتوي على سياسة ، حيث يوجد كود أقل ، وبالتالي أخطاء أقل وتغييرات في التصميم. نريد تجريدات وأنواع _تبادلت_ [1] بين مكتبات الطرف الثالث لإصدارها بشكل غير متكرر [2] لتقليل عدد المشكلات التي تواجهها عند تنسيق التبعيات عبر مخطط حزمة كبير. لا يمكنك تضمين أنواع التبادل أو دمجها كجزء من تطبيقك ، بينما يمكنك تضمين الأنواع غير التبادلية. ومن ثم ، لماذا نريد تقسيمهم.

[1] أعني بكلمة _exchanged_ الأنواع التي تميل إلى الظهور في واجهات برمجة التطبيقات العامة. على سبيل المثال ، نحن نعتبر Collection<T> نوع تبادل ، لكن ليس List<T> .
[2] قد يؤدي استخدام الإصدار الدلالي لهذه إلى حدوث فواصل مماثلة تقريبًا لما ورد أعلاه مع الواجهات التي تمت إزالتها ، لأنك "تفرز" النظام البيئي ؛ تحتاج المكتبات إلى اتخاذ قرار بشأن استهداف المكتبة قبل الفاصل أو بعده ، أو شوكة نفسها للتعامل مع الانقسام.

mythz لا بد لي من دعم orms / العملاء كجزء من تطبيق تجاري وكود حالي ... لا أقول إنني أتفق مع أي من الجانبين ولكن حقيقة الأمر هي أن dnx هو إطار عمل / وقت تشغيل جديد تمامًا. إذا لم يكن يحتوي على بعض الواجهات ، تعامل معه ... مع توجيه مترجم.

إذا لم يكن يحتوي على بعض الواجهات ، تعامل معه ... مع توجيه مترجم.

أوه؟ ماذا عن طريقة تقوم بإرجاع IDataReader ، أو طريقة تقبل IDbConnection؟ أو IDbTransaction؟ كيف ستنتقل إلى #ifdev حول ذلك ، إذا كان رمز _customers_ الخاص بك يستخدم واجهة برمجة التطبيقات هذه؟

تعامل معها .. أي غطرسة هذا؟

بسيط ، قم بتحديث الحزمة الأساسية (مؤسستك) لإرجاع النوع الخاص بك أو النوع الأساسي الذي دعمته منذ 2.0. إذا كنت تستهدف الإصدارات القديمة من .net ، فيمكنك استخدام توجيه لإرجاع الواجهة بدلاً من ذلك وتمييزها على أنها مهملة.

نعم ، هذا سيء ، لكنني متأكد من أنهم (الأشخاص الأذكياء حقًا الذين يفكرون في هذا طوال الوقت) فعلوا ذلك لسبب وجيه في ذلك الوقت (مرة أخرى في .net 2.0). هل يمكن أن يحدث حديث وربما يتغير هذا بالتأكيد .. لكن حقيقة الأمر هي أن الأشخاص الذين يقومون بالترقية إلى وقت التشغيل الجديد سيتعين عليهم القيام ببعض الأعمال. لا يتم النقر فوق زر في واجهة مستخدم رائعة وهناك عمل مقطوع لهم .. ولكن في نفس الوقت ، أتفق معك في أن الترقية إلى إطار العمل الجديد يجب أن تكون أسهل من الذهاب واستبدال مجموعة من الأنواع.

FransBouma هو على الأرجح شخص يدعو إلى تسمية قوية أيضًا.

FransBouma @ phillip-haydon يمكن أن يأخذك في التصيد إلى أماكن أخرى ، ولا يمكنك أن تتوقع أن تتصرف على هذا النحو وأن يأخذك الناس على محمل الجد. ألقِ نظرة على مساهماتي / مشاريعي مفتوحة المصدر ذات الصلة إذا كانت لديك أي شكوك ... سيتعين علي التعامل مع هذا ... في كلتا الحالتين ...

للتسجيل ، أنا ضد التسمية القوية.

تعامل مع...

وأنت تقول إنني أتصيد؟

" FransBouma هو على الأرجح شخص يدعو إلى التسمية القوية أيضًا." خارج الموضوع ، وليس مفيدًا جدًا لهذا الحديث. نعم ، يبدو الأمر وكأنه تصيد الخاص بك ..

إحدى الحقائق المهمة التي يجب مراعاتها في هذه المناقشة هي أن واجهات IDb * تم إهمالها كواجهة برمجة تطبيقات لـ ADO.NET في .NET 2.0 قبل عقد من الزمان عندما تم تقديم الفئات الأساسية. لم يتم وضع علامة على أنها مهملة ، ولكن أي شيء تم بناؤه منذ ذلك الوقت يعتمد على الفئات الأساسية بدلاً من ذلك. يتبادر إلى الذهن موفرو App.config ودعم سلسلة الاتصال.

إذا كان لديك رمز اعتمادًا على تلك الواجهات ، فأنت تقوم بالترميز مقابل واجهة برمجة تطبيقات قديمة جدًا بدون دعم لأشياء مثل الطرق غير المتزامنة ، مما يعني أنك ستحتاج إلى تحديثه على أي حال إذا كنت تريد أن يستمر الأشخاص في استخدامه.

بسيط ، قم بتحديث الحزمة الأساسية (مؤسستك) لإرجاع النوع الخاص بك أو النوع الأساسي الذي دعمته منذ 2.0. إذا كنت تستهدف الإصدارات القديمة من .net ، فيمكنك استخدام توجيه لإرجاع الواجهة بدلاً من ذلك وتمييزها على أنها مهملة.

إنها واجهة برمجة تطبيقات عامة ، تستخدمها عدة آلاف من التطبيقات ، وكانت واجهة برمجة التطبيقات عامة ومستخدمة منذ .net 1.0. إنها ليست "بسيطة" ، على العكس من ذلك. لا يمكننا تغيير واجهة برمجة التطبيقات فقط لأن Microsoft تعتقد أن هذا ما يتعين عليهم فعله لتحسين حياتنا: سيكون عبئًا كبيرًا على مستخدمينا وبالتالي علينا.

نعم ، هذا سيء ، لكنني متأكد من أنهم (الأشخاص الأذكياء حقًا الذين يفكرون في هذا طوال الوقت) فعلوا ذلك لسبب وجيه في ذلك الوقت (مرة أخرى في .net 2.0). هل يمكن أن يحدث حديث وربما يتغير هذا بالتأكيد .. لكن حقيقة الأمر هي أن الأشخاص الذين يقومون بالترقية إلى وقت التشغيل الجديد سيتعين عليهم القيام ببعض الأعمال. لا يتم النقر فوق زر في واجهة مستخدم رائعة وهناك عمل مقطوع لهم .. ولكن في نفس الوقت ، أتفق معك في أن الترقية إلى إطار العمل الجديد يجب أن تكون أسهل من الذهاب واستبدال مجموعة من الأنواع.

هذا هو الشيء: لا يُنظر إليه على أنه "وقت تشغيل جديد". إذا كان هذا هو الحال ، كما ناقشت بالفعل ، فلن تكون هناك مشكلة. ومع ذلك ، لدى Microsoft فكرة أن CoreFX الذي يستهدف dlls يجب أن يعمل على .NET بالكامل أيضًا ، لذلك لا يوجد إطار عمل جديد. بالنسبة إلى المشرفين على المكتبات التي تستهدف .NET كاملة أيضًا ، مع وظائف ليست في CoreFX (لذا فإن الكثير من المكتبات الموجودة اليوم) تتمتع بالكثير من "المرح" حيث سيتعين عليهم الاحتفاظ بنسختين. ليس 2 أو 3 #ifdevs ويتم حل المشكلة ولكن الكثير منها. ربما يكون الأمر مختلفًا بالنسبة لك ، حيث يمكنك ربما فاتورة عميلك بالساعات التي يجب أن تقضيها في تغيير واجهات برمجة التطبيقات. يختلف الأمر عندما تنشئ نظامًا للأغراض العامة يستخدمه الكثيرون.

إذا كان دعم إطار العمل المضغوط يمثل أي إرشادات ، فإن دعم ORM على .net الكامل و CoreCLR سيكون بمثابة إهدار رهيب للوقت ، والكثير من الإحباط ، وفي الواقع لم تكتسب الكثير: لن تحصل على ميزات جديدة ، فأنت تعمل فقط حول _ غياب_ منها .

(وقبل أن يبدأ أحدهم بـ: "لكنها تعمل على نظام Linux ، ستكسب ذلك": تعمل الأشياء لدينا على Mono منذ سنوات عديدة. لذا لا ، إنها ليست ميزة جديدة حقًا تكتسبها ، لقد كانت موجودة بالفعل).

SellMeThisFramework. أوه لماذا أنا حتى أزعج.

ولكن أي شيء تم بناؤه منذ ذلك الوقت يعتمد على الفئات الأساسية بدلاً من ذلك

_cough_ Linq-to-SQL DataContext _cough_

كما تفعل بالفعل العديد من ORMs غير MS ، ومن هنا جاءت المشكلة. لأنيق نحن فقط قليلا
الرصاصة وهاجروا إلى DbConnection. إذا كان لدينا الوقت مرة أخرى ، فأنا
سيقترح بشدة استخدام مرض التصلب العصبي المتعدد [عفا عليه الزمن] عندما يتقادم شيء ما. لكن:
لا يمكننا تغيير الماضي.

ومع ذلك ، تعتبر هذه مشكلة مؤلمة للغاية ، خاصة وأن معظمها
يحتاج مؤلفو المكتبة إلى الاستمرار في استخدام كل من واجهات برمجة التطبيقات (تجميع طريقة واحدة لـ
net40 وما إلى ذلك ، وطريقة أخرى لـ DNX). لقد نشرت سابقًا الفوضى العارمة
التي يستخدمها المتأنق للقيام بذلك: إنها ليست جميلة ، وليست بهذه البساطة

لو.

في 27 نوفمبر 2015 20:07 ، كتب "Natan Vivo" [email protected] :

إحدى الحقائق المهمة التي يجب مراعاتها في هذه المناقشة هي أن IDb *
تم إهمال الواجهات باعتبارها API لـ ADO.NET في .NET 2.0 قبل عقد من الزمن
عندما تم تقديم الفئات الأساسية. لم يتم وضع علامة "مهملة" ، ولكن
أي شيء تم بناؤه منذ ذلك الوقت يعتمد على الفئات الأساسية بدلاً من ذلك.
يتبادر إلى الذهن موفرو App.config ودعم سلسلة الاتصال.

إذا كان لديك رمز اعتمادًا على تلك الواجهات ، فأنت تقوم بالترميز مقابل ملف
واجهة برمجة تطبيقات قديمة جدًا مع عدم وجود دعم لأشياء مثل الطرق غير المتزامنة ، مما يعني
ستحتاج إلى تحديثه على أي حال إذا كنت تريد أن يستمر الأشخاص في استخدامه.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/dotnet/corefx/issues/3480#issuecomment -160198453.

فشلت في رؤية النقطة مع تلك الأساليب غير المتزامنة التي لا يمكن إضافتها نتيجة لاستخدام الواجهات. كان بإمكانك إنشاء واجهات جديدة للطرق غير المتزامنة. IAsyncDbCommand ، IAsyncDataReader إلخ. ثم يمكنك جعل الفئات الأساسية تنفذ كلا النوعين من الواجهات.

مستخدمو ADO.NET إما يستخدمون الإصدار غير المتزامن أو الإصدارات المتزامنة ، وليس كلاهما. لذلك كان من الممكن أن يعمل بشكل رائع.

بالنسبة لمطوري المكتبات ، لا يهم حقًا ما إذا كانت الوظائف تنمو وتظل الواجهات كما هي. أليس هذا هو الغرض؟ تقديم واجهات جديدة لوظائف جديدة. العمل مع الفئات الأساسية هو مجرد ألم.

هل يمكنني فقط تلخيص الخيط هنا؟

العديد من خبراء المجتمع المعترف بهم والمستقلين على أدوات بيانات .NET ،
بما في ذلك العديد من مؤلفي ومشرفين إدارة ORM يخبروك - تمامًا
بوضوح - أن هذا يمثل مجموعة كبيرة من المشاكل. لا اعتقد
يجهل أي منا التفاصيل الدقيقة أو ساذج في البرمجة
المبادئ ، ومعظمنا إن لم يكن جميعًا يعرف جيدًا جميع القصص الخلفية ،
لأننا كنا هناك في ذلك الوقت.

يبدو أن الرد الرسمي هو "يبدو الأمر جيدًا بالنسبة لنا ، وإي أف سعيدة".
نعم نعلم ذلك لأن القرار اتخذ في المقام الأول.

حسنًا ، لقد عبرنا جميعًا عن آرائنا ، حتى لو لم تكن مثمرة.
في 27 تشرين الثاني (نوفمبر) 2015 الساعة 20:41 ، كتب "Jonas Gauffin" [email protected] :

فشلت في رؤية النقطة مع تلك الأساليب غير المتزامنة التي لا يمكن إضافتها كملف
نتيجة استخدام الواجهات. كان بإمكانك إنشاء واجهات _ جديدة لـ
الطرق غير المتزامنة. IAsyncDbCommand ، IAsyncDataReader إلخ. ثم يمكنك ذلك
اجعل الفئات الأساسية تنفذ كلا النوعين من الواجهات.

مستخدمو ADO.NET إما يستخدمون الإصدار غير المتزامن أو المتزامن
الإصدارات ، وليس كلاهما. لذلك كان من الممكن أن يعمل بشكل رائع.

بالنسبة لمطوري المكتبات ، لا يهم حقًا ما إذا كانت الوظائف تنمو و
واجهات تبقى كما هي. أليس هذا هو الغرض؟ أعرض الجديد
واجهات لوظائف جديدة. العمل مع الفئات الأساسية هو مجرد ألم.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/dotnet/corefx/issues/3480#issuecomment -160201361.

الرجال .. تحديث التعليمات البرمجية الخاصة بك ورفع الإصدار الرئيسي الخاص بك. منتهي.

نعم ، ولكن لا يوجد سبب يمنعك من ملء هذه الواجهة بتوجيه مترجم عند استهداف core. لقد فعلت ذلك مع بعض حزم pcl الخاصة بنا.

أعتقد أن Microsoft بحاجة إلى إعادة التأكيد على أن النواة ليست شبكة كاملة ولكن هذا لا يزال غير مفيد .. أعتقد أن Microsoft بحاجة إلى تنظيف بعض الواجهات حتى تكون صادقة. كان هناك منشور مدونة يتم تداوله مؤخرًا حيث توجد واجهات غير متناسقة للغاية ولا تعرف أبدًا أي منها تختار .. أعتقد أن تحديد واجهة غير متزامنة ثانية أمر سيء. سيكون لطيفا إذا كان كل شيء غير متزامن ..

سيكون من الجيد إذا تم تنفيذ إطار العمل الكامل للتأكد من أن الأشياء التي يجب وضع علامة عليها كمتوقفة ... وتم إصدارها كـ 4.6.2

mgravell +100. حسنًا ، وافق 100٪.

ما مدى تأثر حقا؟ نحن نتحدث عن coreclr هنا؟ سوف يظل سطح المكتب .NET على قيد الحياة لسنوات عديدة قادمة حتى يتمكن coreclr من اللحاق بالركب. بالضبط لمن يشتكون ، ما خسارة التغطية هنا؟ كثير من الناس يقولون إنها نهاية العالم.

leppie في الواقع ، سيكون موجودًا لسنوات عديدة. وسيتعين علينا الحفاظ على هذه الاختراقات والحلول في التعليمات البرمجية الخاصة بنا لسنوات قادمة أيضًا. نقطة الخلاف هنا هي إزالة الجسر المشترك بين الاثنين. تم نقل عبء العمل هذا إلى جميع مطوري المكتبة بدلاً من BCL. أنا أفهم كلا الجانبين من إيجابيات وسلبيات الواجهة ، لكنني لا أفهم موقف "الأمر بسيط ، المضي قدمًا" من البعض هنا.

لنكن صريحين هنا: إذا كان على مستهلكي المكتبات فعل الشيء نفسه ، فيجب أن يكون في BCL . النقاش هو "ما هو الشكل الذي يتخذه ذلك؟"

على الجانب الإيجابي لإزالة الواجهات ، هناك آلية إصدار _إضافية_ مع نموذج الحزم الجديد قيد التشغيل الآن: أي الفئات المتوفرة في X و Y و Z أصبحت الآن مدعومة بشكل أفضل من خلال الأدوات. على سبيل المثال dotnet5.2 مقابل 5.4 حاليًا. ولكن هناك عيوب هناك أيضًا. على سبيل المثال ، لا يزال SqlClient غير قادر على تنفيذ الواجهات كما هي اليوم (انظر dotnet / runtime # 14302 و dotnet / runtime # 15269) ، وبالنظر إلى ما قالتهYoungGah (ما لم

إذن ماذا يحدث مع 5.6 (1.5)؟ إذا تمت إضافة المزيد من الأعضاء إلى فئات الملخص ، فمن المتوقع أن يواكب كل مزود بيانات الهدف المتحرك الذي يمكن أن يتغير مع كل شخص متحرك؟ يحتاج كل مستهلك إلى تحديد إصدار بشأن الميزات المتوفرة في كل منها؟ نحتاج إلى تجميع نسخة من التجميع لكل إصدار من النظام الأساسي للمضي قدمًا لمطابقة القاعدة المجردة للفئة التي يتم تمريرها فيها؟ كيف يعمل كل هذا في المضي قدمًا مع الإضافات ليس واضحًا بنسبة 100٪. الواجهة التي لا تتغير تكون أوضح بكثير. علاوة على ذلك ، هناك التوثيق: ما هي الميزات والطرق وما إلى ذلك المتاحة ، وفي أي الإصدارات _والأنظمة الأساسية_ ستكون نقطة ألم كبيرة لجميع مؤلفي المكتبات الذين يمضون قدمًا. هذا القلق هو فقط شبه متعلق هنا ، لكنه يلعب دوره.

أما الآن ، فأنا في انتظار التحديث بفارغ الصبر في الأسبوعين المقبلين. ما أخشاه هو أنه سيكون فعالاً ، كما كانت الرسائل طوال الوقت: "نحن نقوم بـ X لأنه يعمل مع SQL و Entity Framework ، وهذا جيد بما فيه الكفاية" - بدون استخدام أي من هذه الكلمات. كان الإحباط من جانب مؤلف المكتبة ، بالنسبة لي ، هو عدم إحراز تقدم (في كل من الكود والمناقشة) على هذه الجبهات منذ شهور.

أتفق بنسبة 100.

عندما صممت الإصدار 2 (والإصدارات الأحدث) من SqlFu (My Micro ORM) ، كان علي أن أقرر مكان إرفاق طرق الامتداد: إلى DbConnection / DbCommand أو بالواجهات. لقد وجدت هذا وقررت أن أذهب إلى الفصول المجردة.

لذلك ، أنا لست متأثرًا بذلك ، على الرغم من أنني متأثر بإزالة IDataReader ، لأن MS في حكمتهم قررت عدم توضيح الواجهات التي يجب التعامل معها على أنها قديمة وأيها لا ينبغي. لكن في حالتي ، ليس من الصعب استبدال الواجهة.

ومع ذلك ، أرى قيمة وجود واجهات مخصصة ولا أعتقد أنه من الصعب على MS الاحتفاظ بها / إضافتها مرة أخرى. إذا قرروا أن الواجهات القديمة ليست جيدة التصميم ، فلا بأس! صمم الجديد ليكون أكثر تحديدًا. على الأقل في المستقبل لن نضطر للتعامل مع نفس المشكلة.

(هذا هو أسبوع عيد الشكر في الولايات المتحدة ، لذا فإن ردود Microsoft ستكون محدودة جدًا حتى يعودوا إلى المكتب الأسبوع المقبل)

فقط أريد التكرار - حتى لا تفقد أي اقتراحات / أخطاء جيدة في هذا الموضوع ، إذا كانت لديك مشكلات مع الفئات الأساسية الحالية / مساحة السطح ، و / أو طريقة إصدارها للمضي قدمًا ، فيرجى تقديم مشكلة جديدة ، دعنا نحافظ على هذه المناقشة حول واجهات v1 فقط.

NickCraver على غرار التوافق من إصدار إلى إصدار من .NET Framework ، لن تكون هناك تغييرات

davkean ما مدى ثقتك في أن هذا لن يحدث؟ نظرًا لأننا نرى مساحة سطح غير مكتملة ولا توجد ضمانات ستتغير ، فمن الصعب تصديق أن القطع المفقودة لن تظهر لاحقًا على الإطلاق. ومع ذلك ، أعتقد أنه لا توجد تغييرات عاجلة هي الشيء الأكثر أهمية ، وأنا متأكد من أن معظم مؤلفي المكتبات هنا سيفترضون أيضًا. هذا يعني أنه من الأهمية بمكان الاهتمام بهذه العناصر جيدًا قبل وصول RTM.

للتسجيل ، توجد مشكلات منفصلة تم تسجيلها على مساحة السطح ، راجع dotnet / runtime # 14302 و dotnet / runtime # 15269 مع آخر التحديثات من Microsoft في 25 سبتمبر و 2 أكتوبر على التوالي - على الرغم من طلب التحديثات والنشاط عدة مرات بعد ذلك. هذا شهرين و 2 من الإصدارات التي ظهرت في صمت. هذا على الرغم من أن dotnet / وقت التشغيل # 14302 هو أكثر المشكلات

أنا واثق تمامًا من أننا لن نجري تغييرات جذرية ، يبحث فريق Data Common في إجرائها دون تقديم أعضاء مجرد.

NickCraver عذرًا ، نحن نعمل بشكل سيء هنا - لم يتم نسيان هذه المشكلات ، قدمت YoungGah تحديثًا أعلاه عنها ،

تضمين التغريدة

dnx هو إطار عمل / وقت تشغيل جديد تمامًا

إذا كنت تعتقد أن وقت تشغيل dnx ومكتبات corefx تظهر من فراغ ، فأنت تقلل بشكل خطير من الوقت الذي سيستغرقه تطويرها من الصفر. حقيقة أن مكتبات CoreFx تعمل على .NET Framework الكامل يجب أن تعطيك دليلًا على أنه ، لا ، ليس جديدًا تمامًا.

إذا لم يكن يحتوي على بعض الواجهات ، تعامل معه ... مع توجيه مترجم.

نعم ، ولكن لا يوجد سبب يمنعك من ملء هذه الواجهة بتوجيه مترجم عند استهداف core.

إذا كنت قد أزعجت نفسك عناء قراءة التعليقات قبل الانتقال إلى هذا الموضوع ، فستعرف أن أ) هناك أسباب و ب) هذه إستراتيجية مكسورة غير قابلة للتطبيق لواجهات BCL الأساسية.

تضمين التغريدة

إحدى الحقائق المهمة التي يجب مراعاتها في هذه المناقشة هي أن واجهات IDb * تم إهمالها كواجهة برمجة تطبيقات لـ ADO.NET في .NET 2.0 قبل عقد من الزمان عندما تم تقديم الفئات الأساسية.

إذا كان هذا هو الحال ، فلن تكون قد فتحت مشكلة تخبرهم بالعودة إلى استخدام واجهات كنت تعرف عن قصد أن الفئات الأساسية قد أوقفتها قبل عقد من الزمان. الطريقة التي تتواصل بها مع واجهة برمجة التطبيقات (API) التي تم إهمالها هي استخدام السمة [Obsolete] والتي تعد غرضها الوحيد الموجود. إذا لم يتم توصيلها على نطاق واسع ، فلن يتم إهمالها بغض النظر عن أفكارك الآن. يجب أن تعطي حقيقة أن معظم الشركات غير التابعة لـ MS .NET ORM تعتمد عليها إشارة إلى أن إهمالها لم يتم الإبلاغ عنه بشكل جيد ، هذا إذا حدث ذلك أصلاً.

إذا كان لديك رمز اعتمادًا على تلك الواجهات ، فأنت تقوم بالترميز مقابل واجهة برمجة تطبيقات قديمة جدًا بدون دعم لأشياء مثل الطرق غير المتزامنة ، مما يعني أنك ستحتاج إلى تحديثه على أي حال إذا كنت تريد أن يستمر الأشخاص في استخدامه.

قانع مزيف - لا يشير أحدهما إلى الآخر. لقد أضفنا بالفعل دعمًا لواجهات برمجة التطبيقات غير المتزامنة ، ولا ، لم تفسد إضافتها قواعد التعليمات البرمجية الحالية للعميل ولا تحتاج إلى تغيير أي من واجهات برمجة التطبيقات الحالية.

حسنًا ، هذا أمر رائع ، لكن هل يمكنني طرح سؤال واحد: ما التنازلات التي تم إجراؤها لدعم أطر العمل الخاصة بك؟ ما هي أهوال الماضي التي تم ترحيلها لأنها كانت بحاجة إليها لتشغيل Entity Framework ، على سبيل المثال؟

سيكون من العار أن تختفي MicroORMs ، فهي تجعل كود Net يعمل إلى حد ما (إن EF هي وحش غير قابل للاستخدام للتطبيقات حيث يكون 500ms لتحميل بضعة صفوف غير مقبول).

بالنسبة للواجهات مقابل الفئات الأساسية: تعتبر الفئات الأساسية رائعة طالما أن كل ما يمكن إعادة استخدامه هو افتراضي. على سبيل المثال ، أحد أكثر قرارات التصميم المزعجة في WCF هو الاستخدام الواسع للفئات المختومة التي تحتوي على الكثير من الوظائف. لنفترض أنه يتعين عليك إجراء تعديل صغير على الطريقة التي يتم بها التعامل مع رسائل XML (بسبب: التشغيل المتداخل). بدلاً من وراثة وظيفة صغيرة واحدة وتجاوزها ، عليك إعادة تنفيذها. في مثال WCF ، تم تخطي S في SOLID ، لذلك غالبًا ما تُركت في تنفيذ واجهة كبيرة بدون أي من الاختبارات المطلوبة للتأكد من أنها ذات جودة إنتاجية.

لذا ، فإن الفئات الأساسية التي يمكننا تكييفها هي أمر جيد.

أنا واثق تمامًا من أننا لن نجري تغييرات جذرية ، يبحث فريق Data Common في إجرائها دون تقديم أعضاء مجرد.

davkean من المستحيل ضمان ذلك ، وأنت تعرف ذلك. ADO.NET هو نظام فرعي للتواصل مع برامج الجهات الخارجية مع مجموعة متنوعة من الميزات ، والتي يتم عرضها من خلال واجهة برمجة تطبيقات مشتركة مع بعض نقاط الامتداد. تتغير الأشياء ، حتى في أرض قاعدة البيانات ، وهذه التغييرات تموج من خلال واجهة برمجة التطبيقات المستخدمة للتواصل واستهلاك خدمات قواعد البيانات الخارجية هذه. إلى جانب ذلك: التغييرات في السلوك _ هي أيضًا تغيير جذري. وقد رأينا هذه أيضًا في ADO.NET (على سبيل المثال حول معالجة الأخطاء) في السنوات الماضية.

تمتلئ واجهة برمجة تطبيقات ADO.NET بالكامل بالآثار الجانبية لهذه التغييرات ، والتي غالبًا ما يتم تشغيلها بواسطة SQL Server ؛ بالكاد تم تصميم الأشياء بشكل عام ثم نقلها إلى عميل SQL ، ولكن العكس (على سبيل المثال ، ليس هناك العديد من الميزات ، إن وجدت ، في الفئات الأساسية التي يتجاهلها SqlClient). يضاف إلى ذلك الأشياء التي تحتاجها الأطراف الثالثة لم تصل إلى واجهة برمجة التطبيقات.

باختصار ، إنها واجهة برمجة تطبيقات ، في البداية مع .NET 1.0 كان لها تصميم عام (والذي ثبت أنه معيب بشكل خطير في العديد من المجالات) والذي تم إصلاحه منذ ذلك الحين مع ميزات اليسار واليمين للتعامل مع التغييرات في المشهد. _معظمهم لا يزالون في API (إن لم يكن كلهم). والآن ستقوم Microsoft بإزالة واحد: الواجهات.

لا يوجد شيء مطلقًا مكتسبًا عن طريق إزالة جزء عشوائي من واجهة برمجة التطبيقات: لا تتم إضافة أي ميزة من خلال هذا (يمكنك قضاء الوقت في ذلك بدلاً من التراجع هنا على سبيل المثال) ، ولكن التعليمات البرمجية التي تعمل على هذا الجزء من واجهة برمجة التطبيقات لن تعمل. إذا كانت النقطة وراء تحريك كل هذا الجبن هي "البدء من جديد" ، فافعل ذلك بكل الوسائل ، ولكن افعل ذلك عن طريق إعادة تصميم واجهة برمجة التطبيقات لجعلها واجهة برمجة تطبيقات حقيقية للأغراض العامة ، وتخلص من جميع الأجزاء التي تراكمت على مر السنين .

لكن هذا لم يحدث. لا أحد يجب أن يتساءل لماذا ، كلنا نعرف لماذا. نعلم أيضًا أنه إذا تعرض فريق داخل MS لأذى شديد بسبب إزالة الواجهات ، فلن تتم إزالتها في المقام الأول.

إذا تمكنت Microsoft من إضافة وظائف جديدة من خلال الفئات الأساسية بحيث يقوم موفرو الطرف الثالث تلقائيًا بتنفيذ "نموذج من" الميزة (مثل مع Async ، حيث تعود طريقة عدم التزامن إلى طريقة المزامنة إذا لم ينفذها الموفر) ، فهذا أمر رائع: يعني أننا مطورو ORM من الأطراف الثالثة (وواجه الأمر: العديد من المطورين يصلون إلى _your_ API الخاص بك من خلال شفرة ORMs (الصغيرة) التابعة لجهات خارجية) يمكنهم ببساطة استهداف فئة واحدة وهذا كل شيء.

لكن ليس مضمونًا أنك ستفعل ذلك. على سبيل المثال ، لم يزعج أحد داخل Microsoft نفسه بميزات معينة لـ Oracle أو PostgreSql لإضافتها إلى ADO.NET. على سبيل المثال ، استخدام UDTs ، وأشجار المستندات ، ونتائج متعددة من خلال المؤشرات ، يجب على كل موفر ADO.NET أن يجد طريقته الخاصة في التعامل مع هذه الميزات. ماذا لو (متى؟) حصل SQL Server على ميزة شجرة مستندات على سبيل المثال مع مستندات JSON ، فهل سيتم تحديث ADO.NET بواجهة برمجة تطبيقات جديدة لذلك؟ كما فعلت في الماضي مع الإبلاغ عن الأخطاء من موفري ADO.NET؟

لا يمكنك تقديم ضمانات من هذا القبيل ، وليس من الحكمة القول هنا أن MS لن تكسر أي شيء في المستقبل. لقد كان لديهم دائمًا وأحيانًا اضطروا إلى: بعد كل شيء يحتوي كل API على عيوب ، و ADO.NET مليء بها ؛ بطريقة أو بأخرى ، في يوم من الأيام ، سيقوم شخص ما "بإصلاحها".

لذا ، للتلخيص: الواجهات جزء من ADO.NET كما أن الأجزاء الفاشلة في مكان آخر في API هي جزء من ADO.NET. لم تتم إزالة تلك العناصر لإصلاح واجهة برمجة التطبيقات ، كما لم يتم إعادة هيكلة واجهة برمجة التطبيقات لجعلها واجهة برمجة تطبيقات ذات غرض أكثر عمومية: لقد تم تركها كما هي ، مع إزالة بعض العناصر مثل DataSet / Table المعتمدة على العناصر لأنها لم يتم نقلها (وهناك هي قضايا أخرى تناقش ذلك مع تقدم مماثل) ، باستثناء ... تتم إزالة الواجهات.

من وجهة النظر هذه وحدها ، لا يوجد أي معنى بالفعل.

تضمين التغريدة

إذا كان الأمر كذلك ، فلن تكون قد فتحت مشكلة تخبرهم بالعودة إلى استخدام الواجهات التي كنت تعرف عن قصد أنه تم إيقاف العمل بها

لا يمكنك قراءة البروتوكول الاختياري وفهم ذلك. أصبحت هذه المناقشات دينية للغاية وأنت تفترض فقط أشياء لم يقلها أحد.

لقد فتحت هذه المشكلة لأنني أعتقد أن الواجهات أفضل في وصف واجهة برمجة التطبيقات والمساعدة في الاختبار. إذا تم ذلك ، فلا أعتقد أنه يجب أن تكون متوافقة مع واجهة برمجة تطبيقات عمرها 15 عامًا كانت بها مشكلاتها. التوافق مع الإصدارات السابقة لم يكن أبدًا نقطة في المشكلة حتى نقلتم المناقشة إلى ذلك يا رفاق.

لا أعتقد أن الأمور يجب أن تنكسر من أجلها فقط. لكن إصدار الواجهة هو مشكلة من الماضي. إذا قام corefx بتغيير شيء ما بين الإصدارات الرئيسية ، فمن المتوقع أن يكون لإصداراته الرئيسية تغييرات متقطعة. إذا قاموا بفصل واجهة بين الإصدارات الثانوية ، فهذا مجرد إهمال.

لقد أضفنا بالفعل دعمًا لواجهات برمجة التطبيقات غير المتزامنة

لا يمكنك إضافة واجهة برمجة تطبيقات غير متزامنة أعلى واجهة برمجة تطبيقات مزامنة. إذا فعلت ذلك باستخدام IDbConnection أو IDbCommand ، فأنت فعلت ذلك بشكل خاطئ. إذا كنت لا تستخدم هذه الواجهات ، فلن يكون لديك في الواقع أي سبب للدفاع عن أي توافق عكسي معها.

لقد أضفنا بالفعل دعمًا لواجهات برمجة التطبيقات غير المتزامنة

لا يمكنك إضافة واجهة برمجة تطبيقات غير متزامنة أعلى واجهة برمجة تطبيقات مزامنة. إذا فعلت ذلك باستخدام IDbConnection أو IDbCommand ، فأنت فعلت ذلك بشكل خاطئ. إذا كنت لا تستخدم هذه الواجهات ، فلن يكون لديك في الواقع أي سبب للدفاع عن أي توافق عكسي معها.

هذا ما فعلوه في ADO.NET: تعود طرق Async افتراضيًا إلى متغيرات المزامنة. بهذه الطريقة ، لا يتعين على جميع موفري ADO.NET الذين لا يدعمون Async (اقرأ: جميعهم باستثناء SqlServer في هذه اللحظة) تنفيذ أشياء لا يدعمونها: كود طرف ثالث في ORMs يقدم Async api يمكنه البرمجة ضده طرق Async في ADO.NET وإذا كان موفر ado.net لا يدعم التزامن ، فلن يعرف أحد بالفعل. حسنًا ... ستعرف لأنها أبطأ ، لكن بغض النظر عن ذلك.

يعد الآن أيضًا توضيحًا جيدًا لغياب أي "تصميم" أو بنية عامة داخل ADO.NET: لا توجد طريقة لإنشاء نقطة حفظ للمعاملات في واجهة برمجة التطبيقات العامة. على الرغم من أن جميع قواعد البيانات تقريبًا تدعم ذلك باستخدام طريقة "حفظ (سلسلة)" على صنفها المشتق من DbTransaction. الكل باستثناء OleDbTransaction (لأن MS Access لا يدعمها ، على الأقل هذا شكوكي).

الأمر ليس سهلاً ، لكن لم يقله أحد أنه سهل. هذه المشكلة ليست جديدة ، لقد تعامل معها OleDB و ODBC لسنوات عديدة ، ووجدت JDBC طريقة لحلها ، ولا يتعين على Microsoft إعادة اختراع العجلة للتغلب على أشياء مثل هذه. كما أنها ليست فريدة في عالم قاعدة البيانات: على سبيل المثال ، تدعم كل بطاقة فيديو هناك مجموعة فرعية مختلفة من الميزات من خلال واجهة برمجة التطبيقات الخاصة بها ، والتي يتم عرضها للمطور من خلال Direct3D / X. من المثير للاهتمام حقًا كيف تسير التصاميم في هذه العوالم الأخرى: تم تصميم واجهة برمجة التطبيقات ، ويجب على الأطراف التي تحتاج إلى دعمها (برامج تشغيل JDBC ، وكتّاب برامج تشغيل OleDB ، وما إلى ذلك) تنفيذها. السائق الخاص بك لن يدعم X؟ برنامج التشغيل الخاص بك غير متوافق مع X. "لا تدعم Oracle ADO.NET v10". لا أحد في Oracle يريد قراءة ذلك. بدلاً من ذلك ، يكون SqlClient هو الصدارة ، وما يسقط من العربة يضاف إلى ADO.NET وهذا كل شيء.

هذا ما فعلوه في ADO.NET: تعود طرق Async افتراضيًا إلى متغيرات المزامنة.

لا ، ليس كذلك. تعرض واجهة برمجة التطبيقات طرقًا غير متزامنة تتراجع عن طرق المزامنة افتراضيًا ، لكن الموفرين يتجاوزون العمليات غير المتزامنة الحقيقية. ما يقولmythz هو أنه يستخدم IDbCommand و IDbConnection ويقوم بذلك.

هذا غير ممكن ، فترة. إذا قمت بذلك ، فأنت إما لا تفعل ذلك بشكل صحيح أو أنك لا تستخدم الواجهة. لا يمكنك اختراع غير متزامن إذا لم تكن واجهة برمجة التطبيقات الأساسية غير متزامنة.

لا ، ليس كذلك. تعرض واجهة برمجة التطبيقات طرقًا غير متزامنة تتراجع عن طرق المزامنة افتراضيًا ، لكن الموفرين يتجاوزون العمليات غير المتزامنة الحقيقية. ما يقولmythz هو أنه يستخدم IDbCommand و IDbConnection ويقوم بذلك.

لا يوجد موفر رسمي يفعل ذلك باستثناء SqlClient ، كل البرامج الأخرى ، مثل ODP.NET ، لا تنفذ أي شكل من أشكال التعليمات البرمجية غير المتزامنة ، وبالتالي فإن كود الاستدعاء يعود إلى متغيرات المزامنة (الطرق غير المتزامنة في DbDataReader / DbCommand وما إلى ذلك والتي تنفذ فعليًا رمز المزامنة ). لذا فإن كود المستخدم يستدعي متغيرًا غير متزامن ، والذي يوجد تحت غطاء المحرك يقوم بعمليات المزامنة. مما يؤدي إلى عدم تنفيذ عدم التزامن من الناحية العملية (حيث تتم مزامنة جميع التعليمات البرمجية في الممارسة العملية). ربما يطبق مقدمو devart واجهة برمجة تطبيقات غير متزامنة في التنفيذ الخاص بهم ، لكن هذا غير متأكد.

على أي حال ، لا يتعلق الأمر بالقيام بذلك بشكل صحيح ، إنه يتعلق بإصدار واجهات برمجة التطبيقات.

تضمين التغريدة

لقد فتحت هذه المشكلة لأنني أعتقد أن الواجهات أفضل في وصف واجهة برمجة التطبيقات والمساعدة في الاختبار. إذا تم ذلك ، فلا أعتقد أنه يجب أن تكون متوافقة مع واجهة برمجة تطبيقات عمرها 15 عامًا كانت بها مشكلاتها. التوافق مع الإصدارات السابقة لم يكن أبدًا نقطة في المشكلة حتى نقلتم المناقشة إلى ذلك يا رفاق.

حسنًا ، لقد علمت أن واجهات ADO.NET الأساسية قد تم إهمالها منذ 10 سنوات ، مع نقل كل شيء إلى الفئات الأساسية ، ومع ذلك كنت تعتقد أنه يجب عليهم التخلي عن ذلك الآن والعودة إلى الواجهات ، باستخدام نفس الأسماء مثل الواجهات الحالية ، ولكن لم تعد الواجهات الموجودة موجودة ، لأن التوافق مع الإصدارات السابقة ليس مطلوبًا ، أليس كذلك؟ بالتأكيد ، يبدو شرعيًا.

إذا كنت ترغب في المضي قدمًا بمنصة ، فأنت تطور API بمرور الوقت وتدعمها بشكل متوازٍ ، مما يمنح الجميع القدرة على دعم واجهات برمجة التطبيقات المتوازية والسماح لهم بالتخطيط لطريقتهم وعملائهم بعيدًا عنهم. إن تمزيقها دون سابق إنذار يكسر النظام البيئي الذي يعتمد عليها بشكل غير ضروري ويدفع التعقيد إلى كل تبعية في المصب.

لا يمكنك إضافة واجهة برمجة تطبيقات غير متزامنة أعلى واجهة برمجة تطبيقات مزامنة. إذا فعلت ذلك باستخدام IDbConnection أو IDbCommand ، فأنت فعلت ذلك بشكل خاطئ. إذا كنت لا تستخدم هذه الواجهات ، فلن يكون لديك في الواقع أي سبب للدفاع عن أي توافق عكسي معها.

أتمنى أن تتوقف عن تلويث هذا الموضوع بالتعليقات على أشياء من الواضح أنك لا تعرف عنها شيئًا. اقرأ التعليمات البرمجية المصدر إذا كنت تريد معرفة كيفية تنفيذ Async API - وتوقف عن نشر الأكاذيب بشكل أعمى. من المستحيل أن تقوم مكتبة تابعة لجهة خارجية بتوسيع واجهات System.Data. نحن نقدم واجهة برمجة تطبيقات لا تعتمد على التنفيذ والتي من أجل دعم كل RDBMS رئيسي ، تكشف عن الحد الأدنى من التبعية التي ينفذها كل موفر ADO.NET في واجهة API الخارجية - وهي واجهات System.Data الأساسية. Async API هي طرق امتداد خارج IDbConnection والتي تعمل من وراء الكواليس على تعزيز واجهات برمجة التطبيقات غير المتزامنة على موفري ADO.NET الملموسين الذين لديهم دعم لهم. داخليًا ، توجد بالفعل تبعيات محددة على كل موفر ADO.NET مدعوم ، بغض النظر عن الدعم غير المتزامن. اقتراحك بأننا "ليس لدينا في الواقع أي فائدة للدفاع عن أي توافق عكسي معهم" هو اقتراح عديم الخبرة ولا أساس له على الإطلاق.

اسمحوا لي أن أطرح هذا إلى جانب Microsoft من السياج (ج جdavkeanYoungGah): ودعنا نقول انها عالم مثالي ولا شيء يأتي من أي وقت مضى. متى _do_ تريد كسر الأشياء؟ الإصدارات الرئيسية مثل 6.0؟ في وقت آخر؟ الحجة ضد الواجهات هي أنها لا تصدر نسخة. حسنًا ، نعم ، هذا صحيح - لكن _ إذا لم نغير الفئات المجردة أيضًا_ ، فهذه أيضًا نقطة خلافية. إذن ... هل يمكننا الحصول على بعض الوضوح هناك؟

المتابعات:
إذا كانت الإجابة بنعم (ستكون هناك تغييرات في مرحلة ما بعد RTM) ، إذن ما هو نوع الفواصل التي سنراها؟ الإضافات ، طرق جديدة؟ إذا ورثت الفئة الأساسية لمزودي ، فماذا يحدث عند إضافة طريقة متعارضة يستخدمها الأشخاص ، وما إلى ذلك؟

إذا كانت الإجابة بلا (مطلقًا): فلماذا لا تكتفي بإضافة الواجهات مرة أخرى؟

هذا الموضوع معلق بعض الشيء عند المناقشة - الآن - وهو أمر جيد في الغالب لأن هذه الأشياء تحتاج إلى إصلاح في أسرع وقت ممكن. يعرف كل مؤلف مكتبة هنا مدى صعوبة الحصول على أي شيء بعد إتمام الإصدار ، ولهذا السبب نضغط بشدة. لسوء الحظ ، يؤدي عدم وجود خطة واضحة للإضافات والتغييرات المستقبلية ، إن وجدت ، إلى مزيد من الحجج الأقل استنارة.

ما هي الخطط للمستقبل؟

لا ينبغي أن نفرض التنفيذ عبر فئات مجردة في هذه الحالة. IMO

لن تقوم Microsoft بإجراء تغييرات يتم كسرها لـ .NET 4.5. إنه جزء من Windows. التوافق هو الملك.

قد تقوم Microsoft بإجراء تغييرات لا تؤثر على الإصدار 4.5 من .NET Core. أشك في أنهم سينشرون 1.0 RTM على مستوى منخفض مثل ADO.NET ، لكن الشريط أقل. إنه ليس جزءًا من Windows ويمكن نشر إصدارات .NET Core جنبًا إلى جنب.

يمكن تغيير الفصول المجردة - هذا لا ينكسر. ما عليك سوى إضافة طريقة افتراضية مع تطبيق افتراضي. لقد تم بالفعل باستخدام طرق ADO.NET غير المتزامنة. مع تقديم NET Core ، أعتقد أن التغييرات في الفئات المشتركة يجب أن تتم بالتنسيق مع إصدارات .NET 4.5 للحفاظ على التوافق. شخص ما يصحح لي إذا كان هذا خطأ ولا ينطبق إلا على الواجهات: ابتسامة:

تضمين التغريدة

لا يوجد موفر رسمي يفعل ذلك باستثناء SqlClient ، لا تنفذ جميع البرامج الأخرى ، مثل ODP.NET ، أي شكل من أشكال التعليمات البرمجية غير المتزامنة ، وبالتالي فإن رمز الاستدعاء يعود إلى متغيرات المزامنة

أنت محق ، لكن هذه ليست مشكلة مع واجهة برمجة التطبيقات ، والمزيد من الكسل أو قلة الفهم من قبل المنفذين. قام موصل MySql على سبيل المثال بإعادة تنفيذ جميع طرقه غير المتزامنة عن طريق إنشاء TaskCompletionSource وإكمالها باستخدام طرق المزامنة ، وهو أمر سخيف. يمكنهم فقط حذف نصف قاعدة التعليمات البرمجية الخاصة بهم والبقاء على نفس السلوك.

إن عدم القول إن الواجهات ستحل ذلك ، ولكن عدم وجود سلوك افتراضي لعدم التزامن سيجعل البعض على الأقل يفكر في هذا الأمر. حقيقة أن 90٪ من الأشخاص الفنيين جدًا لا يفهمون العمليات غير المتزامنة لا تساعد أيضًا.

يمكن تغيير الفصول المجردة - هذا لا ينكسر. ما عليك سوى إضافة طريقة افتراضية مع تطبيق افتراضي. لقد تم بالفعل باستخدام طرق ADO.NET غير المتزامنة.

هذا كسر. إنه كسر لجميع المكتبات التي صنفت هذا التطبيق فرعيًا دون معرفة أنه تمت إضافته ثم يستهلك الناس هذا التفكير. أوه ، هذا التنفيذ مدعوم الآن مع postgresql BAM ERROR حدث wtf ...

التنفيذ الإجباري لتجريد db خطأ.

لا يهم إذا كانت واجهاته أو فئة أساسية. ستكون هناك تغييرات كبيرة. لكن التنفيذ الإجباري المحدد مسبقًا خطأ.

لا يعمل تعدد الأشكال بهذه الطريقة. لا يمكنك تجاوز طريقة دون معرفة ذلك. إذا كان مرجعك هو DbConnection وقمت باستدعاء QueryAsync ، فسوف يقوم باستدعاء هذه الطريقة فقط أو أي شيء تم تجاوزه باسم. لن يتم استدعاء طريقة تسمى QueryAsync كانت موجودة بالفعل في فئة فرعية.

أنت محير في تجاوز طريقة آيات لإخفائها بنفس الاسم.

تضمين التغريدة

إذا تم تعريف الأساليب على أنها مجردة ، فلا يوجد تنفيذ في الفئة الأساسية. هذا يخرق العقد للأطراف الثالثة حيث يتطلب منهم إضافة التنفيذ في الفئة الفرعية.

إذا جعلت الطريقة افتراضية بحيث يمكن تجاوزها ، فإن التنفيذ موجود في الفئة الأساسية والذي قد لا يكون له أي معنى بالنسبة للفئة الفرعية. هذا لا يزال معطلاً بسبب وجود تطبيق لم يتم تنفيذه بواسطة مؤلف المكتبة. تأكد من أن التطبيق الخاص بك يمكن أن يترجم ، وكل شيء على ما يرام ، لكن شخصًا ما يسمي هذه الطريقة ، وهي غير صالحة للفئة الفرعية. ذلك خطأ. هذا هو التنفيذ القسري الذي لا ينتمي إلى الطبقة الفرعية.

لذلك ، فئة مجردة حيث يمكن أن يوجد التنفيذ والتي لا تنتمي إلى الفئة الفرعية. أو واجهات لا يوجد فيها تنفيذ افتراضي للأطراف الثالثة.

@ phillip-haydon لهذا السبب تم تطبيقه كطريقة افتراضية وليست طريقة مجردة.

يمكنك إضافة أشياء ستؤدي فقط إلى كسر الفئات الفرعية التي لديها بالفعل عضو بنفس التوقيع (الاسم / args). إذا كانت args مختلفة ، فقد يؤدي ذلك إلى حدوث أخطاء خفية إذا أخطأ المطورون في التحميل الزائد.

هذا هو التنفيذ القسري الذي لا ينتمي إلى الطبقة الفرعية.

ثم لا تضعه هناك.

تضمين التغريدة

لا تضعه هناك. لهذا السبب نجادل في إزالة الواجهات.

جعلها افتراضية لا يحل المشكلة. يجب ألا يكون هناك تنفيذ محدد مسبقًا. نهاية القصة

JamesNK في هذه الحالة ، لم نضعها هناك ، وضعها _Microsoft_ هناك من خلال تضمينها في الملخص. إضافة الطرق التي يُفترض أنها تعمل عبر _ جميع_ مقدمي الخدمة الذين يرثون من أي وقت مضى ، فأنا لا أرى حقًا أن تسير بسلاسة بكفاءة حتى لو لم يتم كسرها تقنيًا (سأتنازل عن "يجب استخدام" تحذيرات تجميع جديدة _تقنيًا_ لا يتم كسرها). ببساطة لن يكون هناك تنفيذ مشترك أو مشترك على الفور في _ Most_ الحالات. إذن ما هو البديل؟ throw new NotImplementedException() داخل ذلك الظاهري؟ هذه ليست حجة لوجودها في المقام الأول ، فهي مليئة بالمزيد من مشاكل (وقت التشغيل).

دعونا نلقي نظرة على اليوم: أفضل أن أرى إضافة IDbAsyncConnection عندما يدعمها مقدم الخدمة بدلاً من مجموعة من الأساليب المتزامنة تحت الأغطية مما يؤدي إلى الارتباك وعدم الكفاءة ، وهو ما لدينا اليوم بشأن هذه الملخصات.

من الأفضل أن أرى إضافة IDbAsyncConnection عندما يدعمها مقدم الخدمة بدلاً من مجموعة من الأساليب المتزامنة تحت الأغطية مما يؤدي إلى الارتباك وعدم الكفاءة

@ نيك هنا حيث فريق أوراكل لا يفهم معنى غير المتزامن.

يمكنك فعل ذلك مع الواجهات. تكمن المشكلة معهم في أنه لا يمكنك قبول الحجج التي تتطلب واجهات متعددة ، على سبيل المثال ، أحتاج إلى نوع من النوع IDbAsyncConnection و IDbConnection. تفقد الكتابة القوية وعليك أن تبدأ في الاستعلام عن واجهات نمط COM الذي لا أعتقد أنه سهل الاستخدام للغاية. إنها أداة في تصميم واجهة برمجة التطبيقات لها مكانها ولكني لا أعرف ما إذا كنت سأذهب إليها افتراضيًا.

إذا كان التنفيذ الافتراضي هو إلقاء NotImplementedException ، فإن تثبيته في الفئة الأساسية هو الشيء الخطأ الذي يجب القيام به. كما قلت ، لا تضعها هناك بعد ذلك. إذا رأيت شخصًا يفعل ذلك ، فقم بإثارة مشكلة.

في كلتا الحالتين ، سواء كانت واجهات أو فئات أساسية مجردة ، فإن تجربتي تضيف ميزات جديدة إلى مكتبة لم يتم تصميمها في الأصل لهم دون كسر العالم أمر صعب للغاية.

يُفترض أن JamesNK IDbAsyncConnection سيرث IDbConnection هنا ، لكن ليس بالضرورة أن يكون هذا هو الحال - يمكنهم مشاركة أعضاء مشتركين أو يرثون من قاعدة مشتركة. على سبيل المثال في Dapper من المحتمل أن ننفذ على النحو التالي:

ج #
لا تعداستفسار(هذا IDbConnection cnn ، CommandDefinition cmd)

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

أتخيل أن معظم المكتبات ذات أساليب المزامنة / غير المتزامن لها استخدامات وتطبيقات مماثلة.

_ تعديل: _ بعد الكتابة أدركت كم سيكون أفضل Async في نهاية الاسم لكل هذه ...

كان لدى ADO.NET التغييرات الرئيسية التالية على مر السنين:

1. في عام 2003 (1.1) قاموا بتغيير كسر من 1.0 وأعادوا تصميمه
2. في 2005 (2.0) انتقلوا إلى نموذج الموفر مع الفئات الأساسية الموجودة اليوم
3. في عام 2012 (4.5) أضافوا دعمًا غير متزامن ، والذي لم يغير شيئًا فعليًا بخلاف إضافة طرق جديدة تقوم بنفس الأشياء بشكل غير متزامن.

العودة إلى الطريقة التي تم بها تعريف واجهة برمجة التطبيقات لعام 2003 هو تغيير سيؤدي إما إلى كسر التوافق (الذي لا يريده الأشخاص) أو إزالة الميزات المضافة في العقد الماضي. لكن إضافة واجهة جديدة إلى .NET Core بالتصميم الحالي تتوافق مع المصدر مع أي إصدار من .NET. إعادة التحويل البرمجي هو كل ما تحتاجه للحفاظ على عمل معظم الشفرات المكتوبة في آخر 15 عامًا. وسوف تحتاج إلى إعادة التحويل البرمجي على أي حال لاستهداف corefx.

كانت واجهة برمجة التطبيقات هذه مستقرة لفترة طويلة. يمكن إعادة تصميمه كواجهات إذا أراد الناس. كالعادة ، لا توجد مشكلات فنية هنا ، فهي تتلخص في الندوب والتفضيلات والأنا.

لماذا لا تعيد الواجهات مرة أخرى وتضع علامة عليها عفا عليها الزمن؟

على الرغم من إسقاط هذه الفكرة ، إلا أنني أتساءل عما إذا كان من الممكن أن تساعد الأسطح المحايدة للتجميع في هذا النوع من المواقف ، انظر هذا http://davidfowl.com/assembly-neutral-interfaces/ ثم تنفيذها
http://davidfowl.com/assembly-neutral-interfaces-implementation/

أعتقد أن واجهات التجميع المحايدة هي هالة حمراء هنا ؛ إذا كان أي شيء
أن يحدث ، هذا شيء "شائع" تمامًا ، نظرًا لوجود "مشترك". بالإضافة إلى ذلك
موضع نقاش منذ أن تبخرت الميزة.
في 28 نوفمبر 2015 5:38 مساءً ، كتب "شهيد خان" [email protected] :

على الرغم من إسقاط هذه الفكرة ، إلا أنني أتساءل عما إذا كان التجميع محايدًا
كان من الممكن أن تساعد الاستنتاجات في هذا النوع من المواقف انظر إلى هذا
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();
}

تضمين التغريدة

الأشخاص الذين يقفون وراء فكرة CoreClr (إطار عمل لامع جديد) لديهم عقلية مختلفة تمامًا عن الأشخاص الذين يقفون وراء تنفيذها (التوافق مع الإصدارات السابقة مع قاعدة بيانات عمرها 15 عامًا هو الملك).

شكرًا لتوضيح ذلك ، يبدو أنه يحتاج إلى الإشارة. بشكل عام ، أعتقد أن فرق MS تهتم بشدة بالتوافق مع الإصدارات السابقة وهو أمر حيوي لتطوير كل من اللغات ومنصاتهم. إنها فقط القرارات المتعلقة بالنظام. لا يتم اتخاذ البيانات مع مراعاة النظام البيئي الأوسع - والذي يجب أن تخدمه هذه الأفكار التجريدية الأساسية على قدم المساواة.

• عن طريق إزالة الواجهات أنت تجعل الأمور أسوأ.
• لا شيء عفا عليه الزمن حتى يتم تزيينه بـ [قديم]. ولا يهم من يفكر ماذا في أي وقت. هذا هو العقد ، وإذا كنت ببساطة لا تفي به ، فأنت لست كذلك.

بدقة.

بخصوص إصدار واجهات. صححني إذا كنت مخطئًا لكنني اعتقدت أن نقطة CoreClr هي إصدار أكثر دقة واستقلالية؟ كسر التغيير؟ فقاعة! تم إصدار نسخة رئيسية جديدة.
يبدو أنه بعد 15 عامًا من الخبرة في التصميم ، سوف تكرر نفس الأخطاء ولكن الآن لديك إصدار مستقل وحزم nuget. الحجج المذكورة أعلاه مطابقة للإطار القديم الجيد المتجانس ، على الرغم من أنه لم يعد كذلك.
إذا كان التوافق مع الإصدارات السابقة أمرًا ضروريًا ، فلا يمكنك إزالة تلك الواجهات. إذا لم يكن الأمر كذلك ، فلنتوقف عن الحديث عنها ونصمم واجهة برمجة التطبيقات من البداية ، وهذه المرة نستمع إلى مؤلفي ORM الرئيسيين وغيرهم من المطورين ذوي الخبرة في ADO.NET.
شكرا لك.

abatishchev نقاط جيدة جدا. تساءلت عن نفسي أيضًا: ما هو الهدف الحقيقي من حجة التوافق العكسي؟ إذا تمت إضافة ميزة جديدة إلى CoreClr ، فلن يتم تشغيل كل شيء يستخدمه على .net بالكامل ، لذا حتى يكون آمنًا ، لا يمكن للمرء سوى استخدام السلوك الشائع. (هذا لم يعمل بشكل جيد).

آسف للصمت الطويل من جهتي.

النقل إلى NET Core

أولاً ، دعنا نتحدث عن الفيل في الغرفة ، وهو أن NET Core لا يحتوي تقريبًا على العديد من واجهات برمجة التطبيقات المتاحة كما يأمل العديد من الأشخاص - بمن فيهم نحن -.

أنا أعمل مع فريقي لتجميع مجموعة من المستندات حول كيفية تعاملنا مع مجال نقل الأصول الحالية إلى .NET Core.

نحن نخطط لنقل المزيد من الوظائف الموجودة حاليًا فقط في .NET Framework / Mono إلى .NET Core. ستوضح هذه الوثيقة كيف سنفعل ذلك ، وكيف نعطي الأولوية ، وما هي الآليات. لا أود أن يحدث هذا العمل في العراء فحسب ، بل أود أيضًا تمكين المجتمع من مساعدتنا في نقل المزيد من الوظائف.

كسر التغييرات

هناك مجال واحد يسبب الكثير من الارتباك عندما يتحدث الناس عن NET Core. دعني أوضح شيئًا واحدًا:

لا يعد تغييرًا جذريًا إذا كان NET Core يحتوي على واجهات برمجة تطبيقات أقل من .NET Framework.

السبب هو أن NET Core هو نظام أساسي جديد ويمكن أن يحتوي تقنيًا على مجموعة عشوائية من واجهات برمجة التطبيقات. ومع ذلك ، بالطبع ، لا نريد مجموعة عشوائية - هذا ما فعلناه في الماضي. الهدف من NET Core هو الحصول على قصة حيث يمكن للأشخاص تأليف مكتبات (ومع تطبيقات وحدة التحكم إلى نطاق معين حتى التطبيقات) التي سيتم تشغيلها على .NET Framework و .NET Core. يتطلب هذا وجود مجموعة فرعية من كلا النظامين الأساسيين متوافقين بنسبة 100٪. في هذا السياق ، ستسمعنا نتحدث عن تغيير التغييرات.

علاوة على ذلك ، نهدف إلى الحصول على شريط متوافق عالي ضمن .NET Core. بعبارة أخرى ، لا نخطط لإجراء تغييرات فصل واجهة برمجة التطبيقات بين إصدار واحد من .NET Core API وآخر.

واجهات

تعد إضافة أعضاء إلى الواجهات - بحكم التعريف - تغييرًا جذريًا. يجادل بعض الناس بأن التأثير منخفض وأن هناك طرقًا لنمذجة ذلك ، ولكن كما هو الحال اليوم ، فهو تغيير ثنائي ومصدر.

WinRT ، الذي يعتمد على COM وبالتالي يعتمد بشكل كبير على الواجهات ، يحل هذه المشكلة عن طريق إنشاء المزيد من الواجهات ، مثل IFoo ، IFoo2 ، IFoo3 . إنها قابلة للتنفيذ ، لكنها بالتأكيد فوضوية بدون ميزة وقت التشغيل أو اللغة لجعلها محتملة. حتى الآن ، هذه الميزة غير موجودة. ومع ذلك ، بصفتي عضوًا في فريق تصميم اللغة ، فأنا مهتم جدًا بسماع المقترحات. اللغات والأنظمة الأساسية الأخرى لها أفكار ذات صلة في تلك المساحة ، وأنا أبحث بنشاط في الخيارات أيضًا (مثل الخلطات / السمات ، أو ملحقات Swift ، أو الأعضاء الافتراضيون للواجهات).

نظرًا لأننا لا نزال نهتم بالتوافق مع الإصدارات السابقة ، فإننا نفضل عمومًا أنواع القواعد المجردة على الواجهات.

واجهات ADO.NET

كل ما يقال ، دعنا نتحدث عن السؤال الأصلي في مؤشر الترابط هذا: كشف واجهات موفر ADO.NET.

كما أوضح ديفيد: لقد اعتبرنا أن هذه الواجهات مهملة عندما تم تقديم أنواع القواعد المجردة ، والتي كانت في .NET 2 / Visual Studio 2005. يبدو أن هناك اعتقادًا قويًا بأن وجود هذه الواجهات أمر بالغ الأهمية لمنفذ إطارات عمل ORM إلى .NET Core. بالنسبة لي ، يوفر هذا دليلًا كافيًا على أنه يجب علينا نقل الواجهات إلى .NET Core.

ومع ذلك ، كما هو الحال مع جميع واجهات برمجة التطبيقات الجديدة ، نحتاج إلى الانتباه إلى أحد الأهداف الأساسية لـ .NET Core ، وهو وجود مكدس مكون. الواجهة IDataReader لها تبعية على DataTable ، والتي تعتمد على DataSet . كما هو موضح في dotnet / وقت التشغيل # 14302 ، لا نعارض إضافة دعم لـ DataTable لكننا نعتبر DataSet إرثًا. ومع ذلك ، قد لا نزال نضيفها كحزمة منفصلة ، ولكن في كلتا الحالتين ، سيتطلب ذلك كسر سلسلة التبعية من الواجهات -> DataTable -> DataSet . سأعمل مع YoungGah لمعرفة ما يمكننا القيام به هناك.

هل سيعالج هذا النهج المخاوف؟

ما لم أكن مخطئًا ، فإن تبعية DataTable الوحيدة في IDataReader هي ملف
طريقة GetSchemaTable () ، تمت مناقشتها مطولاً في DataTable
سلسلة. ومع ذلك ، فإنني أعترف بسهولة أن حقيقة وجود ملف
نأمل في إضافة _ بعض _ وظائف مماثلة في وقت لاحق (سواء
عبر DataTable أم لا) يجعل من الصعب جدًا الكشف عن هذا على
الواجهة ، لأن تمديد الواجهة لاحقًا يمثل مشكلة. لن يكون الأمر كذلك
بسيطة تمامًا مثل "إزالة الطريقة في الوقت الحالي ، وإضافة شيء آخر لاحقًا"
في 5 ديسمبر 2015 الساعة 12:17 صباحًا ، كتب "Immo Landwerth" [email protected] :

آسف للصمت الطويل من جهتي.
النقل إلى NET Core

أولاً ، دعنا نتحدث عن الفيل في الغرفة ، وهو .NET
لا يحتوي Core على العديد من واجهات برمجة التطبيقات المتاحة تقريبًا مثل العديد من الأشخاص - بما في ذلك
لنا - نأمل.

أنا أعمل مع فريقي لتجميع مجموعة من المستندات حول كيفية تقدمنا
للاقتراب من منطقة نقل الأصول الحالية إلى .NET Core.

نحن نخطط لنقل المزيد من الوظائف الموجودة حاليًا فقط
موجود في .NET Framework / Mono إلى .NET Core. هذه الوثيقة سوف تنادي
كيف سنفعل ذلك ، وكيف نعطي الأولوية ، وماذا ستفعله الآليات
يكون. لا أود أن يحدث هذا العمل في العراء فحسب ، بل أود ذلك أيضًا
تمكين المجتمع يساعدنا في نقل المزيد من الوظائف.
كسر التغييرات

هناك مجال واحد يسبب الكثير من الارتباك عندما يتحدث الناس عنه
NET Core. دعني أوضح شيئًا واحدًا:

لا يعد تغييرًا جذريًا إذا كان NET Core يحتوي على واجهات برمجة تطبيقات أقل من .NET
إطار العمل.

السبب هو أن NET Core هو نظام أساسي جديد ويمكنه تقنيًا
لديك مجموعة عشوائية من واجهات برمجة التطبيقات. ومع ذلك ، بالطبع ، لا نريد ملف
مجموعة تعسفية
http://blogs.msdn.com/b/dotnet/archive/2014/12/04/introducing-net-core.aspx
- هذا ما فعلناه في الماضي. الهدف من .NET Core هو الحصول على ملف
قصة حيث يمكن للناس تأليف مكتبات (ومع تطبيقات وحدة التحكم إلى ملف
تمديد حتى التطبيقات) التي سيتم تشغيلها على .NET Framework و .NET Core. هذه
يتطلب وجود مجموعة فرعية من كلا النظامين الأساسيين وهي 100٪
متوافق. في هذا السياق ، ستسمعنا نتحدث عن تغيير التغييرات.

علاوة على ذلك ، نهدف إلى الحصول على شريط متوافق عالي ضمن .NET Core.
بعبارة أخرى ، لا نخطط لإجراء تغييرات كسر واجهة برمجة التطبيقات بينهما
إصدار واحد من .NET Core API وآخر.
واجهات

تعد إضافة أعضاء إلى الواجهات - بحكم التعريف - تغييرًا جذريًا.
يجادل بعض الناس بأن التأثير منخفض وأن هناك طرقًا للنمذجة
ذلك ، ولكن كما هو الحال اليوم فهو تغيير ثنائي ومصدر كسر.

WinRT ، الذي يعتمد على COM وبالتالي يعتمد بشكل كبير على الواجهات ،
يحل هذه المشكلة عن طريق إنشاء المزيد من الواجهات ، مثل IFoo و IFoo2 و
IFoo3. إنه قابل للتنفيذ ، لكنه بالتأكيد فوضوي بدون وقت تشغيل أو
ميزة اللغة لجعلها محتملة. حتى الآن ، هذه الميزة غير موجودة.
ومع ذلك ، بصفتي عضوًا في فريق تصميم اللغة ، فأنا مهتم جدًا بذلك
سماع المقترحات. اللغات والمنصات الأخرى لها أفكار ذات صلة في ذلك
space ، وأنا أبحث بنشاط في الخيارات أيضًا (مثل
mix-ins / السمات ، أو ملحق Swift لكل شيء ، أو الأعضاء الافتراضي لـ
واجهات).

نظرًا لأننا لا نزال نهتم بالتوافق مع الإصدارات السابقة ، فإننا نفضل بشكل عام
أنواع القواعد المجردة على الواجهات.
واجهات ADO.NET

كل ما قيل ، دعنا نتحدث عن السؤال الأصلي في هذا الموضوع:
كشف واجهات موفر ADO.NET.

كما أوضح ديفيد: اعتبرنا هذه مهملة عند القاعدة المجردة
تم تقديم أنواع ، والتي كانت في .NET 2 / Visual Studio 2005. على ما يبدو
أن هناك اعتقادًا قويًا بأن وجود هذه الواجهات أمر بالغ الأهمية
إطارات عمل منفذ ORM إلى .NET Core. بالنسبة لي ، هذا يقدم أدلة كافية
أنه يجب علينا نقل الواجهات إلى .NET Core.

ومع ذلك ، كما هو الحال مع جميع واجهات برمجة التطبيقات الجديدة ، نحتاج إلى الانتباه إلى أحد
الأهداف الأساسية لـ .NET Core ، والتي تتمثل في وجود مكدس مكون من مكونات. ال
واجهة IDataReader لها تبعية على DataTable ، الذي يحتوي على ملف
الاعتماد على DataSet. كما هو موضح في dotnet / runtime # 14302
https://github.com/dotnet/corefx/issues/1039 ، نحن لا نعارض إضافة
دعم DataTable ، لكننا حقًا لا نريد نقل DataSet. وبالتالي
ستتطلب إضافة الواجهات كسر هذه التبعية. سأعمل مع
مع YoungGah https://github.com/YoungGah لمعرفة ما يمكننا القيام به هناك.

هل سيعالج هذا النهج المخاوف؟

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/dotnet/corefx/issues/3480#issuecomment -162115855.

نعم ، يعتمد IDataReader على DataTable الذي يعتمد على DataSet.

كما ذكرنا سابقًا ، لا يمكننا إزالة الأعضاء من الواجهات ، لذلك سنحتاج إلى كسر هذه التبعية بطريقة أخرى ؛ إما عن طريق عدم نقل الواجهة ، أو كسر DataTable -> تبعية DataSet.

هل سيعالج هذا النهج المخاوف؟

نعم ، ستؤدي استعادة واجهات ADO.NET حتى بدون استخدام طريقة GetSchemaTable() إلى حل التبعيات الثقيلة في مشكلات واجهة ADO.NET التي أواجهها حاليًا.

أفترض كسر DataTable -> تبعية DataSet إذا كان ذلك يعني أنه سيتم أيضًا تضمين GetSchemaTable() ، سيكون النهج المفضل لأولئك الذين يعتمدون على GetSchemaTable() (لذلك سيكون هذا هو تصويتي) - ولكن سأعطي المزيد من الثقل للمطورين الذين يؤثر ذلك.

terrajobst أشكرك على

terrajobst شكرا على الملخص والتوضيحات. أحتفظ بـ Npgsql لذا فأنا أكتب من منظور موفر ADO.NET ، وليس من منظور ORM.

في .NET Core ، يبدو أن Microsoft لديها الرغبة في إزالة بعض الميزات القديمة القديمة لـ ADO.NET ، مثل DataTable / DataSet والواجهات. يؤدي هذا إلى إنشاء واجهة برمجة تطبيقات أفضل وأنظف للمضي قدمًا ، ولكنه يخلق عملاً جوهريًا للمستخدمين الذين يعتمدون بالفعل على الواجهات وواجهة برمجة تطبيقات DataTable / DataSet.

أنا شخصياً أعتقد أن قتل DataTable / DataSet أمر جيد ، وأنه يجب تقديم واجهة برمجة تطبيقات بيانات وصفية جديدة وأفضل (أعتقد أن هذا صحيح حتى بدون قتل DataTable / DataSet). أنا لا أقوم بالتقليل
الألم الناجم عن هذا الانهيار لمستهلكي ORM (وغيرهم) ، ولكن هناك شيء واحد يجب تذكره وهو أنه إذا كانت هناك فرصة للتنظيف وإدخال الكسر - فإن .NET Core هي تلك الفرصة.

هناك عامل محبط إضافي هنا وهو أن الاحتفاظ بواجهات ADO.NET يعني أيضًا الاحتفاظ DataTable / DataSet أيضًا. بعبارة أخرى ، على الرغم من أنني شخصيًا لا أشعر بشدة بمشكلة الواجهات ، فإن الاحتفاظ بها يعني الاحتفاظ بجدول البيانات / مجموعة البيانات وهذا يبدو أكثر إشكالية.

نظرًا لأنني لا أعرف عدد ORMs الموجودة هناك والتي لا تزال تعتمد على الواجهات ، وأنا أيضًا لا أعرف مقدار الجهد الذي سيتعين عليه الانتقال إلى الفئات الأساسية ، فالخيار ليس كثيرًا واضح هنا. لكن شعوري الغريزي هو اغتنام هذه الفرصة وتنظيف الأشياء حتى لو كان ذلك يعني أن بعض الناس يعانون ...

ملاحظة: مهما فعلت ، لا تسلك طريق انفجار الواجهة ، مثل IFoo2 ، IFoo3. هذا مجرد حل.
إذا قررت إنشاء واجهة برمجة تطبيقات بيانات تعريفية جديدة غير DataTable في .NET Core وتريد تشغيل مكتبات .NET Core في .NET Framework ، فهذا يعني أنه سيتعين عليك إصدار .NET Framework جديد مع واجهة برمجة التطبيقات الجديدة بالإضافة إلى NET Core.

terrajobst شكرا لكسر الصمت؛). أعتقد أن المشكلة الأساسية هي عدم وجود تصميم لـ ADO.NET. لم يكن هناك بعض الوقت وهو يظهر في أجزاء مختلفة من API وهو خليط من الميزات المبطنة دون التفكير في الأشياء لأكثر من دقيقتين (على ما يبدو). أتفق مع roji على هذا: NET core هي فرصة لمرة واحدة في العمر للقيام بشيء حيال الأشياء ، لذا لا ينبغي أن تتراجع .NET core عن (في رأيي ، سخيفة) القاعدة التي يجب أن تكون متوافقة مع الإصدارات السابقة .NET ممتلئ.

ومع ذلك ، إذا لم تتغير الأمور للأفضل بالنسبة لـ ADO.NET (أي تحصل على تصميم حقيقي حيث يتم تصميم واجهة برمجة تطبيقات عامة والتي يتم تخصيصها بعد ذلك في SqlClient وليس العكس! لذا فإن الميزات المتوفرة ليست في تتم إضافة SQL Server ولكن في قواعد البيانات الأخرى إلى واجهة برمجة التطبيقات العامة ولا يتم تركها لكاتب موفر ADO.NET) ، ثم أفضل شيء تالي هو نقل أكبر قدر ممكن ، بما في ذلك الواجهات ونحن مطورون تابعون لجهة خارجية #ifdef أنفسنا حول الحفر التي سيتم تركها.

يمكن أن تكون تبعية DataTable مشكلة ، حيث أن واجهة IDataReader ستجعل من الصعب الاحتفاظ بالأشياء متوافقة مع .NET full _if_ datatable بأي شكل لم يتم نقله. لكن أعتقد أن هذه قضية خاسرة على أي حال. قيل من قبل MS عدة مرات أن .NET full لن يتلقى العديد من التحديثات المتكررة مثل .NET core ، لذلك إذا تمت إضافة شيء _ جديد_ إلى .NET core ، فلن يتمكن أحد من استخدامه ، لأن استخدامه يجعل المكتبة يتعارض على الفور مع .NET الكاملة. من المحتمل أن أفتقد شيئًا ما هنا ، لذا إذا كان الأمر كذلك ، فيرجى تصحيحه :)

هذا وحده يجعله موقفًا غريبًا: يجب أن يكون هناك توافق مع الإصدارات السابقة ، ولكن من الناحية العملية ، يبدو هذا صعب المنال على أي حال. IMHO إذا تم تناول ذلك أولاً ، يمكن استخدام نتيجة ذلك لاتخاذ قرارات مناسبة بشأن ما يجب فعله مع واجهات برمجة تطبيقات .NET core ، أي تحسينها بدلاً من سحب cruft القديم ذي التصميم السيئ من .NET بالكامل. هذا لا يعني أن جميع واجهات برمجة التطبيقات مصممة بشكل سيئ ، ولكن مع ADO.NET (كما وصفت في منشور سابق) ، لم يتم تنفيذ الأشياء بشكل صحيح لسنوات عديدة. إجراء استراحة نظيفة وبدلاً من ذلك تنفيذ نظام يمكن أن يكون أكثر قوة (لا يزال JDBC قويًا ، ولا يزال ODBC يعمل كما كان قبل 25 عامًا) والتكيف مع التغيير هو الأفضل.

بالتفكير أكثر قليلاً في هذا الأمر ، فإن تعليق

أفهم أن التوافق مع الإصدارات السابقة هو مطلب يتجاوز هذه المناقشة الخاصة بـ ADO.NET ، وأنا أتساءل فقط.

إنها الطريقة الأخرى حول roji : يتم تمكين التكرارات القصيرة من خلال عدم كسر واجهات برمجة التطبيقات.

إذا كنت مطورًا .Net واستمر بنائك في التعطل كل أسبوع لأن واجهة برمجة التطبيقات الخاصة بإطار العمل الأساسي تتغير باستمرار ، فلن يمر وقت طويل قبل أن تبدأ في التفكير في نظام أساسي آخر.

لذا فهو تكرار سريع مدفوع بتغييرات غير منقطعة.

(معدل)
يمكنك فقط التكرار دون كسر التغييرات حتى تضطر على سبيل المثال إلى إضافة شيء ما إلى واجهة الفصل أو تغيير السلوك (!) أو إضافة السلوك ، وهو ليس تغييرًا جذريًا بالمعنى الحرفي (تغيير السلوك هو tho) ، ولكن استخدامه على .net core سيجعل الكود الخاص بك غير متوافق مع .net ممتلئ ، وبهذا المعنى فإنه سيجعل .net core غير متوافق مع الإصدارات السابقة بعد الآن مع .net full _ لهذا الجزء من الكود. أي IMHO يأتي إلى .NET core دائمًا ما يكون له نفس واجهات (الفئة) والسلوك كما هو الحال في .NET full ، إلى البايت الأخير (وهو IMHO غير مستدام) أو سيحصل على ميزات جديدة يتم نقلها لاحقًا (وهو حرفياً ما قال MS راجع للشغل) إلى .NET ممتلئ ، مما يجعله غير متوافق مع الإصدارات السابقة. يعتمد ذلك على أي جانب من السياج أنت بالطبع: إذا قلت: "هناك مجموعة مشتركة من واجهات (فئة) X مع سلوك محدد B ، ويقوم كل من .NET core و .NET بتنفيذها بالكامل و X & B فاز" t change in the future '، فهذا يعني أن هناك إطارًا جديدًا خارج X & B سيحصل على أشياء جديدة وهو بالضبط المكان الذي يمكن أن تتغير فيه الأشياء وأيضًا حيث يكمن المستقبل.

يمكن للمرء أن يذهب بعيدًا جدًا مع هذا ، على سبيل المثال ، أن الواجهات / الفئات المستخدمة في X & B في. net core هي في الواقع أغلفة حول الفئات / الواجهات الجديدة في .NET core. يعود الأمر بعد ذلك إلى المطور لاستخدامها إما X & B أو الجديدة مع تصميم أفضل وبدون واجهة برمجة تطبيقات مشتركة مع .NET full.

نظرًا لأننا مضطرون بالفعل إلى #ifdef في طريقنا للتغلب على الأشياء المفقودة في X & B ، عند دعم كلا الإطارين ، فمن الأفضل IMHO أن نكون قادرين على استهداف واجهات / فئات جديدة في .NET core بمجرد تغيير السلوك عاجلاً أو آجلاً (ربما حتى خفية للغاية ، مثل استثناء مختلف في حالة معينة) سيظهر هناك على أي حال ، لذا فإن "نقل" الكود إلى .NET core باستخدام واجهة برمجة التطبيقات الجديدة (وليس X & B) سيكون أفضل. علينا أن نتنقل على أي حال ، على الأقل هكذا أراها.

ryanbnl ، أتفق مع FranBouma. النقطة ليست أننا نريد أن نكون قادرين على كسر واجهات برمجة التطبيقات. إن تقييد NET Core ليكون قابلاً للتشغيل ضمن .NET Framework يعني أنك لن تتمكن أبدًا من إضافة أي شيء إلى أي واجهة .NET Core ، أو إضافة عضو مجرد إلى أي فئة أساسية مجردة. لا يؤدي هذان التغييران إلى كسر التوافق مع الإصدارات السابقة بأي معنى حقيقي لأي شخص يستخدم .NET Core ، بل إنهما يكسران التوافق مع .NET Framework.

roji ما لم تكن حزمة خارجية جديدة من إطار العمل (على سبيل المثال ليس GAC) عندما يمكن أن تكون متوافقة مع كل من Framework و core وتعمل وفقًا لإيقاعها الخاص ؛ ولكن بعد ذلك قد يكون هذا المزيد من التغييرات لموفري ORM والاسم System.Data.IDbConnection مستخدم بالفعل ...

benaadams هذا تعليق صالح - لم يكن لدي سوى واجهات برمجة تطبيقات لإطار عمل غير nuget مثل ADO.NET. ومع ذلك ، يبدو أنها تغطي مساحة كافية لواجهة برمجة التطبيقات لتكون مصدر قلق - لن يتمكن .NET Core من تطوير أي من هذه (اقرأ: إضافة طرق واجهة أو أساليب مجردة) دون أن تصبح غير قابلة للتشغيل

لست متأكدًا مما تقصده بخصوص IDbConnection على الرغم من ...

roji تعني فقط حزمة جديدة توفر هذه الأنواع على سبيل المثال System.Data.Database ؛ لتظل متوافقة مع كل من الأساسية والكاملة ، لا يمكن إعادة تعريف أي أنواع من شأنها أن تكون GAC في إطار العمل الكامل أو قد تتعارض.

على نقطة nuget لأي سبب من الأسباب لا يمكن أن يعيش هذا في كتلة صلبة لكليهما الكامل والجوهر ؛ وإيقاف وظيفة API الحالية System.Data 4.6.1+؟

من شأنه أن يسبب المزيد من الألم الآن ؛ ولكن تم كسر بعض المتوافقة بالفعل ، حيث يتم إسقاط الواجهات ، أو إسقاط DataSet لذلك يجب إجراء بعض إعادة العمل بالفعل لـ coreclr بواسطة موفري ORM.

يمكن لواجهة برمجة تطبيقات جديدة تمامًا تعيش في nuget وخارج إطار عمل GAC أن تكون متوافقة مع الإصدارات السابقة للاستخدام مع netstandard1.2 ، على سبيل المثال 4.5.2+ ، و coreclr ، و UWP ، و mono / Xamarin وما إلى ذلك ، على الرغم من أنه سيكون المزيد من الألم الآن - ولكن ربما يكون الوقت أفضل من وقت لاحق.

بالنظر إلى أن واجهات برمجة التطبيقات الجديدة قيد التشغيل من أجل achema ، فإن الإشارة إلى DataSet لن تظهر (أو DataTable ) ، فهل يجب إغلاق هذا؟ يبدو أن الفئات الأساسية هي السبيل للمضي قدمًا استنادًا إلى التعليقات في dotnet / corefx # 5609 وإعادة توجيه الكتابة ، مما يعني أن الواجهات ليس لها أي فائدة بالنظر إلى GetSchemaTable() وبعضها الآخر ليس موجودًا لتقديمها للتوافق ...هل يجوز قول ذلك؟

يجب ما يغلق؟ إذا لم يكن بإمكاننا الحصول على GetSchemaTable() بسبب تبعية DataTable / DataSet ، فهذا شيء واحد ، ولكن لا يزال يتعين استعادة الواجهات (بدون GetSchema إذا لزم الأمر) وتسهيل نقل قواعد التعليمات البرمجية الحالية مع التبعيات العميقة عليها. الواجهات المفقودة عبارة عن مانع ، ما زلت أنتظر إصدارًا معهم قبل أن نبدأ العمل لدعم dnx / core.

أتفق مع mythz ، الواجهات موضوع آخر وهام للغاية. ربما ليس لمعظم المستخدمين ، لكن هؤلاء المستخدمين أنفسهم يستخدمون رمزًا تكتبه مجموعة صغيرة وهذا الرمز _is_ يعتمد على هذه الواجهات (بالإضافة إلى ميزات ADO.NET المهمة الأخرى المفقودة مثل DbProviderFactory).

لأكون صادقًا ، مع الدفع الشديد نحو تسمية "RTM" ، لدي أمل ضئيل في أن نحصل على واجهة برمجة تطبيقات قوية مع 1.0. سيكون مثل .NET 2.0 مرة أخرى: سيتم بعد ذلك تصحيح جميع الأخطاء التي ارتكبها الإصدار الأول.

تضمين التغريدة

ستكون إضافة الواجهات إلى .NET Core بمثابة تغيير إضافي. لذا ، حتى لو لم يتم قطع V1 ، فيمكن إضافته في أي إصدار تالي ، حتى 1.1.

سيتم بعد ذلك تصحيح جميع الأخطاء التي ارتكبها الإصدار الأول.

بلا إهانة ، ولكن هذه هي الطريقة التي يعمل بها البرنامج.

تضمين التغريدة

لذا ، حتى لو لم يتم قطع V1 ، فيمكن إضافته في أي إصدار تالي ، حتى 1.1.

نعم ، ليس الأمر أنه غير ممكن تقنيًا ، بل أن نتائج القيام بذلك (أو عدم القيام بذلك) لها عواقب (بعيدة المدى) ، والتي لا تعاني Microsoft منها ، نحن. حتى الآن رأيت القليل من اللامبالاة لذلك. من الرائع والمثير العمل على أطر عمل جديدة ، لكن لم يتم تطويرها في غرفة نظيفة لجمهور جديد. ليس الأمر كذلك ، ليس هناك تاريخ للتعلم منه ، بل على العكس.

بلا إهانة ، ولكن هذه هي الطريقة التي يعمل بها البرنامج.

انظر ، هذا بالضبط ما أعنيه أعلاه: أنت لست الشخص الذي يتعين عليه التعامل مع عواقب قراراتك ، يجب أن أفعل. وقد تعاملت بالفعل مع عواقب قرار مشابه من قبل أسلافك ، لذلك أعطيتك تنبيهًا حتى لا ترتكب نفس الخطأ.

أعرف كيف يعمل البرنامج ، لقد كنت مطور برامج محترفًا الآن لأكثر من 21 عامًا. أعطيت نصيحتي الصادقة ، ليس كمبتدئ ولكن كخبير متمرس في المعركة في هذا المجال بالذات. يمكنك أن تفعل ما تريد به ، إنه فقط آمل أن تفكر مرتين قبل اتخاذ قرار بسيط هنا ، حيث أن العواقب بعيدة المدى ، وكما قلت: علينا التعامل مع هؤلاء ، وليس أنت.

حتى الخطأ يمكن إصلاحه لاحقًا ، لكنه لم يرتكب بعد ، إنه سبب وجيه لعدم القيام بذلك في المقام الأول ، أليس كذلك؟

أنتم يا رفاق تبالغون في رد فعلكم. أشك في أن آثار هذا سيكون لها نفس العواقب مثل .NET القديمة كان لها.

مع تضمين coreclr في كل تطبيق ، يكون للإرث معنى مختلف تمامًا. كما هو الحال إلى حد كبير ، لا أحد يهتم إذا لم يتم تحويل الميزات من asp.net mvc 5 إلى mvc 4 أو 3. سيكون للإرث هنا معنى مختلف ، وهناك تاريخ في مشاريع أخرى لإظهار ذلك.

الشيء الجيد أن terrajobst مفتوح للنظر في هذا في الإصدارات التالية.

nvivo من فضلك لا تحاول التقليل من العواقب _I_ يجب أن أتعامل معها ، لأنك لست مضطرًا للتعامل معها ، لكني أفعل.

شكراً لـ FranBouma على وضعي في مكاني. لقد كان خطئي أن أعتقد أنه يمكنني التعليق على هذه القضية. أنت بالتأكيد مؤهل أكثر مني لمعرفة نوع الأشياء التي تؤثر على عملي.

في الواقع ، على الرغم من أنني فتحت الإصدار ، إلا أنه ليس له أي تأثير على عملي أو الأشياء التي أهتم بها. كنت أفكر فقط في المطورين الفقراء مثلك الذين يقومون بكل العمل الشاق على هذا الكوكب.

أنا سعيد حقًا بوجود أشخاص مثلك هنا للاهتمام بالمشاكل الصعبة. من فضلك لا تتردد في إخبارنا مرارًا وتكرارًا (ومرة أخرى) بمدى أهمية المشكلات التي يجب عليك التعامل معها.

شكرا لكFransBouma.

_sigh_ أين أقول كل هذا؟ كل ما أقوله هو من فضلك لا تقلل من شأن الأشياء ، كما تفعل ذلك بـ "أنت تبالغ في رد الفعل" ، لا أعتقد أنني أبالغ في رد الفعل. بعبارة "لست مضطرًا للتعامل معهم" أعني: العواقب على _me_. لأنني أعرف ما هي ردود أفعالي بالطريقة التي فعلت بها. يبدو أن هذا "رد فعل مبالغ فيه".

لكن مهما يكن.

لدينا إجابات لهذه المشكلة هنا وهنا .

الجواب الرسمي هو: لن تكون الواجهات على .NET Core 1.0 ، وعلى الرغم من أنها غير مرجحة ، يمكن اعتبارها للإصدارات المستقبلية في شكل مختلف عما كان موجودًا على .NET.

أقوم بإغلاق هذه المشكلة حيث تمت معالجة السؤال الأصلي.

nvivo شكرًا ، ولكن من الأفضل ترك أي ردود رسمية للأشخاص المسؤولين فعليًا عن المشروع القادرين أيضًا على إغلاق المشكلات بأنفسهم بمجرد أن يقرروا حلها.

terrajobst هل هناك رد رسمي / جدول زمني محدث

دعونا نترك هذا مفتوحا الآن. بالطريقة التي أراها ، لم تكن الإجابة "دعونا لا نكشف الواجهات". كان الجواب "دعونا نجد طريقة لفضحهم ولكن دعونا نفكر في ما يعنيه ذلك بالنسبة للاعتماد على DataTable".

آسف للعودة إليكم في وقت متأخر جدا يا رفاق. بعد مناقشة الخيارات المختلفة داخل فريقنا ، قررنا إعادة الواجهات بفئة فارغة من DataTable. إنه ليس حلاً مثاليًا ، ولكن نظرًا للإطار الزمني لـ RTM ، سيضمن هذا النهج أنه يمكننا متابعة خيارات قابلة للتطبيق حول DataTable / DataSet في المستقبل. سنحاول إحضار واجهات System.Data.Common بواسطة v1 RTM ؛ لن يقوم SqlClient بتنفيذ الواجهات بواسطة v1. شكرا لملاحظاتك وصبرك. ملاحظاتك هي جزء أساسي من جعل مكدس البيانات منتجًا قابلاً للتطبيق.

YoungGah thx للتحديث ، إذا كانت فئات DataTable ستكون مجرد عناصر نائبة فارغة ، فما الذي يتطلب الكثير من الوقت / الجهد (أي منعها) من تنفيذها بواسطة SqlClient v1؟

mythz التكلفة في تنفيذ الواجهات من النوع الأساسي / إعادة توجيهها إلى الأساليب الموجودة. يجب أن تكون التكلفة قليلة ، ولكن عادة ما تظهر الأشياء: ابتسم:

لقد أضفنا الواجهات التالية إلى .Net CoreFX في System.Data.Common

IDataParameter
IDataParameterCollection
إداتاريدر
IDataRecord
IDbCommand
IDbConnection
IDbDataParameter
IDbTransaction

تم ذلك في العلاقات العامة https://github.com/dotnet/corefx/pull/6359

@ saurabh500 الأشياء العظيمة ، تشك!

: +1:

: +1:

مذهل؛ هل هناك علامة فارقة لهذا أن تصل إلى كتلة صلبة؟ rc3؟

في 25 فبراير 2016 الساعة 02:54 ، سوراب سينغ [email protected]
كتب:

لقد أضفنا الواجهات التالية إلى .Net CoreFX في System.Data.Common

IDataParameter
IDataParameterCollection
إداتاريدر
IDataRecord
IDbCommand
IDbConnection
IDbDataParameter
IDbTransaction

تم ذلك في العلاقات العامة 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 ، حيث يجب أن تكون الطرق غير المتزامنة هي الطريقة الافتراضية للوصول إلى أي قاعدة بيانات اليوم. بدون دعم حقيقي للأساليب غير المتزامنة ، تكون هذه الواجهات عديمة الفائدة للتطوير الحديث
تطوير.

وحتى بما في ذلك الطرق غير المتزامنة من .NET 4.5 ، يجب إضافة بعض الطرق الإضافية ، مثل DbTrabsaction.CommitAsync أيضًا.

أضاف موفر postgres بعض الطرق الإضافية مثل CommitAsync إلى واجهة برمجة التطبيقات الخاصة بهم والتي تعد مفيدة وضرورية للغاية.

الواجهات الحالية جيدة كما هي. الآثار المترتبة على تغييرها كبيرة جدًا.

يختلف النموذج غير المتزامن تمامًا عن النموذج المتزامن وكما تعلم ، إذا ذهبت إلى النموذج غير المتزامن ، فيجب عليك القيام بذلك على طول الطريق. ومن ثم لا يوجد سبب حقيقي لامتلاك نفس الواجهات لكل من واجهات برمجة التطبيقات. إنشاء برامج جديدة لواجهة برمجة التطبيقات غير المتزامنة.

إذا أراد فريق .NET توفير واجهة برمجة تطبيقات أكثر حداثة ، فلماذا لا تقوم فقط بإنشاء واجهة برمجة تطبيقات جديدة لا تسمى ADO.NET؟ لا يوجد إرث يمكن إعاقته ولا شكاوى من المجتمع. يتناسب هذا أيضًا بشكل جيد مع كيفية توزيع dnx؟ على سبيل المثال ، الحزم المستقلة.

: +1: على الواجهات ، حل وسط جيد.

لا أعتقد أن الفكرة يجب أن تكون متوافقة فقط مع الكود القديم.

هذه هي الفكرة _entire_ هنا. خلاف ذلك ، ستكون الفئات الأساسية جيدة. هذا قدر كبير من الألم الذي نريد تجنبه.

بدون دعم حقيقي للأساليب غير المتزامنة ، تكون هذه الواجهات عديمة الفائدة للتطوير الحديث.

أنا لا أتفق مع هذا ، لكنني لا أعارض بالضرورة نسخة غير متزامنة من الواجهات (التي لا ينفذها أحد اليوم). ستكون هذه ميزة جديدة. لا يمكننا إضافة أعضاء بأثر رجعي إلى الواجهات الموجودة ، والتي تؤدي إلى كسر الكثير من الأشياء. الحصول على IDbReaderAsync أو شيء ما ليس مجنونًا IMO ، لكنه مناقشة مختلفة.

أعتقد بشدة أن طرق async يجب ألا تكون في الفئات الأساسية ، إذا كان التنفيذ الافتراضي عبارة عن غلاف مزامنة - فهذا أمر سيء ومهدر. إذا كان هناك اقتراح آخر ، فليكن ، ولكن مرة أخرى: يجب أن تكون هذه مشكلة مختلفة على أي حال.

حسنًا ، ربما عبرت عن نفسي بطريقة خاطئة هنا أو كنت قويًا جدًا بكلماتي.

أنا أؤيد واجهة إضافية لـ غير المتزامن إذا لزم الأمر. ما لست موافقًا عليه هو وجود شيء يحدد عقدًا رسميًا لـ ADO.NET (هذا هو المقصود بالواجهات) ولكن لا يحتوي على طرق غير متزامنة في أي مكان فيه.

ولكن بعد ذلك ، من المحتمل أن يتسبب وجود واجهات بديلة للطرق غير المتزامنة في حدوث مشكلات أخرى ...

أعتقد بشدة أن الطرق غير المتزامنة لا ينبغي أن تكون في الفئات الأساسية ، إذا كان التنفيذ الافتراضي عبارة عن غلاف مزامنة - فهذا سيء ومهدر بشكل فعال.

أوافق ، هذا هو السبب الرئيسي وراء عدم إزعاج معظم مقدمي الخدمة بتنفيذ واجهة برمجة تطبيقات غير متزامنة حقيقية. لكن تغيير ذلك من شأنه كسر المزيد من التعليمات البرمجية وربما يتسبب في ضوضاء أكثر بكثير من إزالة الواجهات ، حيث أن الفئات الأساسية كانت واجهة برمجة التطبيقات الفعلية لمقدمي الخدمة منذ الإصدار 2.0.

إن ترقية المكتبة لعدم استخدام أي من الواجهات 1.1 قد يتسبب في حدوث تأثير صفري تقريبًا مقارنة بإزالة جميع التعليمات البرمجية غير المتزامنة المكتوبة في السنوات الماضية ، وهذا سيكون كارثيًا. الحل الوسط هو الحصول على كليهما. يجب أن يستخدم أي كود مكتوب اليوم واجهات برمجة تطبيقات غير متزامنة ، لذا فإن ترك ذلك بالخارج لا معنى له.

يجب أن يستخدم أي رمز مكتوب اليوم واجهات برمجة تطبيقات غير متزامنة.

لا أريد أن أجرح بشدة ، لكن هذا العالم المثالي بعيد جدًا عن الواقع. Async منتشر جدا ومعد. لا يمكنك الاعتماد فقط على واجهات برمجة التطبيقات غير المتزامنة في المكتبات وتتوقع أن تكون التطبيقات بأكملها مستهلكين غير متزامنين (تغيير جزء من التعليمات البرمجية ليكون غير متزامن أيضًا) لمجرد نزوة. المزامنة -> Async في كل مكان أمر سيء للغاية أيضًا للعديد من أسباب الجمود والكفاءة. سيكون هناك رمز متزامن مكتوب لسنوات عديدة قادمة.

هناك حاجة ماسة لكل من واجهات برمجة التطبيقات. النقطة المهمة هي: دعونا لا نزيل المجموعات الحالية أو نؤخر وجودها لمجموعة جديدة افتراضية لم يتم تصميمها بعد. يمكننا القلق بشأن المجموعة الثانية / الجديدة بشكل مستقل.

ترقية مكتبة لعدم استخدام أي من الواجهات 1.1 قد يؤدي إلى عدم وجود تأثير تقريبًا مقارنة بإزالة جميع التعليمات البرمجية غير المتزامنة المكتوبة في السنوات الماضية

لماذا تقصدون؟ لا توجد واجهات برمجة تطبيقات غير متزامنة لمثل هذا الرمز. إذا كنت تعتمد على واجهات برمجة التطبيقات هذه ، فهي ليست على فئة أساسية أو واجهة ، ولكن على موفر بشكل مباشر. لن يتأثر ذلك.

يجب أن يستخدم أي كود مكتوب اليوم واجهات برمجة تطبيقات غير متزامنة ، لذا فإن ترك ذلك بالخارج لا معنى له.

إن ترك الكثير من الأشياء لا معنى له ... باستثناء حقيقة أننا جميعًا مقيدون بالموارد (خاصة الوقت). لا أعتقد أن أي شخص قد ترك أي شيء _ بشكل دائم_. لا شيء خارج الطاولة. إنه ببساطة لم يتم الوصول إليه بعد. سأفتح مشكلة أخرى على وجه التحديد لبدء المواصفات على واجهات غير متزامنة لجيل المستقبل.

لماذا تقصدون؟ لا توجد واجهات برمجة تطبيقات غير متزامنة لمثل هذا الرمز. إذا كنت تعتمد على واجهات برمجة التطبيقات هذه ، فهي ليست على فئة أساسية أو واجهة ، ولكن على موفر بشكل مباشر. لن يتأثر ذلك.

قدم .NET 4.5 طرقًا غير متزامنة على فئات الموفر الأساسية. كان هذا في عام 2012 ، منذ ما يقرب من 4 سنوات ، لذلك كان جزءًا من واجهة برمجة تطبيقات موفر ADO.NET لفترة من الوقت. يعتمد Entity Framework 6 (الذي تم إصداره في 2013) على واجهات برمجة التطبيقات غير المتزامنة لجميع الموفرين.

تعد طرق عدم المزامنة بالفعل جزءًا من ADO.NET لفترة كافية بحيث يصرخ الكثير من الأشخاص إذا لم يتم تضمين ذلك في .NET Core. لدي رمز _legacy_ يستخدم أساليب غير متزامنة في ADO.NET.

أنا أدعو إلى أنه نظرًا لأنهم جزء بالفعل من ADO.NET ، يجب أن يكون هذا موجودًا على واجهة API الجديدة أيضًا.

إذا أراد الأشخاص (ويجب عليهم) استخدام واجهات برمجة التطبيقات غير المتزامنة ، فيمكنهم فعل ذلك بالفعل
قبل هذا التغيير باستخدام الأنواع الأساسية. في النهاية ، الطلب
لدعم الواجهات تم لأسباب التوافق العكسي ؛
إضافة طرق إلى واجهة _ تهب هذا تمامًا من الماء_.
ومع ذلك ، فهو في الواقع ممكن مثل _طرق التمديد_ و
التحقق من الكتابة مقابل أنواع القواعد المجردة ، ولكن ... قبيحة جدًا وليست كذلك
يستحق الألم IMO.

وبالتالي؛ إصدار قصير: لا يمكنني شخصيًا أن أتخلى عن إضافة غير متزامن إلى ملف
واجهات ، لأن ذلك يدمر الشيء الوحيد الذي أردناه في البداية
مكان. إذا كنت تريد غير متزامن: فأنت بحاجة إلى الترميز مقابل الفئات الأساسية ، أو استخدام
الأدوات التي تتستر على هذه التفاصيل من أجلك.

أنا أدافع عن ذلك نظرًا لأنها بالفعل جزء من ADO.NET ، يجب أن يكون هذا موجودًا على واجهة API الجديدة أيضًا.

أنت تسيء فهم تمامًا الغرض من واجهات ADO.NET هذه وهو الحفاظ على التوافق مع التعليمات البرمجية الموجودة. هذه ليست واجهات _جديدة ، هذه واجهات _ موجودة_. إذا كنت ترغب في الوصول إلى أحدث واجهات برمجة التطبيقات ، فارجع إلى أنواع القواعد الملموسة.

nvivo Apologies ، أنا فقط لا أتابعك - كنت أتحدث عن واجهات برمجة تطبيقات _interface_ - هذه لم تكن موجودة من قبل. تحتوي الأنواع الأساسية بالفعل على جميع طرق *Async - هل هناك شيء محدد مفقود؟ أعتقد أنك تجادل بأنه يجب تجميعها في واجهات ... نعم بالتأكيد ، لكن هذه مشكلة أخرى أشجعك على فتحها.

من الأفضل أن يكونوا واجهة منذ البداية لأن عمليات التنفيذ الأساسية اللازمة لجعل النهج الحالي يعمل (غير المتزامن عبر المزامنة) هي مقايضات رهيبة لجعل النهج بأكمله يعمل. لكن ، لا يمكننا أيضًا الحصول على كلا الاتجاهين: إما أن ينتقلوا إلى واجهات أو أنهم موجودون (كما هو الحال حاليًا) لتقليل فترات الراحة.

نعم ، أعتقد أننا نسير في دوائر هنا. لقد ذكرت هذا من قبل ، لا أعتقد أنه يجب إضافة واجهات _just_ للمساعدة في نقل الكود. من وجهة نظر التوافق ، كانت الفئات الأساسية هي واجهة برمجة التطبيقات الرسمية لـ ADO.NET منذ 2005 ، وهذا ما ينفذه الموفرون. يمكن بسهولة نقل أي شيء يستخدم IDbCommand أو IDbConnection (ويجب نقله) لاستخدام الفئات الأساسية مع بحث / استبدال وليس له جوانب سلبية.

أعلم أنك لست من محبي ifdefs ، لكن دعم هذا لمنصة جديدة سيكون جزءًا من الترحيل على أي حال.

أوافق على أن هذا كان يجب أن يكون واجهات طوال الوقت ، لكن نظرًا لأنها لم تكن كذلك ، أود أن أرى هذه المشكلة لا تكرر نفسها. إذا تمت إضافة واجهات ، فيجب أن تمثل واجهة برمجة التطبيقات الحالية على الأقل ، وليس ما كانت عليه قبل عقد من الزمان. تعد طرق عدم التزامن جزءًا لا يتجزأ من واجهة برمجة التطبيقات الحالية وهذا هو الاتجاه الذي تتحرك فيه Microsoft لبعض الوقت. سيظل متوافقًا مع المصدر ، فقط أكثر اكتمالاً.

تضمين التغريدة

إذا أراد الأشخاص (ويجب عليهم) استخدام واجهات برمجة التطبيقات غير المتزامنة ، فيمكنهم فعل ذلك بالفعل قبل هذا التغيير باستخدام الأنواع الأساسية.

هذا لا يتعلق بالقدرة على فعل أي شيء. يتعلق الأمر بالهندسة المعمارية. الواجهات عبارة عن عقود ، NET Core هو إطار عمل جديد يضيف هذا العقد إلى نسخة معاد تصميمها من API.

يجب ألا يضيف .NET core عقدًا رسميًا إلى واجهة برمجة تطبيقات جديدة فقط للمساعدة في ترحيل التعليمات البرمجية القديمة حقًا ، بينما ستفقد معظم العناصر الأخرى على أي حال. إذا كان هذا مصدر قلق ، فإن الأشخاص لا يبحثون بشكل كافٍ عن الأسباب التي سيحتاجون إليها لتغيير التعليمات البرمجية الخاصة بهم على أي حال.

إذا كان هذا كل ما يفعله الفريق ، فهذا جيد .. إنه مجرد خيار سيء IMO.

يمكن بسهولة نقل أي شيء يستخدم IDbCommand أو IDbConnection (ويجب نقله) لاستخدام الفئات الأساسية مع بحث / استبدال وليس له جوانب سلبية.

خاطئة. تمت مناقشة القضايا عدة مرات في هذا الموضوع من قبل مؤلفي مكتبات متعددين لديهم خبرة مباشرة متأثرة بهذا الموضوع.

أعلم أنك لست من محبي ifdefs

أي حلول تتطلب من العملاء النهائيين استخدام ifdefs هي تجربة مطورة معطلة وغير مبتدئة ، أي لن يكون هناك منتج ناجح يتطلب من العملاء إلقاء رمزهم باستخدام #defs عند وجود بدائل.

إذا تمت إضافة واجهات ، فيجب أن تمثل واجهة برمجة التطبيقات الحالية على الأقل

هذه ليست واجهات جديدة ، إنها واجهات مستعادة. واجهات برمجة التطبيقات الحالية والمستقبلية هي الفئات الأساسية ، وليس هذه الواجهات. يجب ألا تكون هناك مشكلة هنا ، يمكنك أن تنسى وجود هذه الواجهات والاستمرار في استخدام الأنواع الأساسية تمامًا كما كان الحال قبل استعادة هذه الواجهات.

لا توجد قيمة جديدة تضاف إلى هذا الموضوع بعد الآن. تمت استعادة واجهات ADO.NET الموجودة بحيث يمكن وضع مؤشر الترابط هذا في وضع الراحة. الشيء الوحيد المطلوب من هذا الموضوع هو تحديثات DataTable و GetSchemaTable() لأنها تتعلق بالواجهات الحالية. إذا كنت ترغب في اقتراح تغييرات معمارية أو الدعوة إلى واجهات جديدة ، فافتح مشكلة جديدة - والتي ستمنع كل فرد في هذه القائمة من التعرض للرسائل غير المرغوب فيها.

mythz دعونا نتفق على الاختلاف.

مجرد إضافة 2 سنت لي كمطور ORM آخر ، فالفئات المجردة هي دائمًا رائحة كود عندما لا تكون مدعومة بواجهة. أرغب في رؤية واجهات جديدة مقدمة لمطابقة الفئات المجردة وتوقيعات الأسلوب المحملة بالحد الأدنى من واجهة برمجة التطبيقات لواجهة المتطلبات.

ممتاز للمجتمع للتحدث.

الفصول المجردة هي دائمًا رائحة كود عندما لا تكون مدعومة بواجهة

psibernetic هل يمكنك مساعدتي في فهم هذا البيان؟ ماذا عن هذا هو رمز الرائحة؟

تضمين التغريدة

تمنحنا الواجهات والفئات المجردة عقدًا ، وكلاهما يمنحنا تجريدًا وتعريفًا جيدًا لواجهة برمجة التطبيقات. تكون الواجهات مفيدة للغاية عند تنفيذ الفئات التي يمكنها تنفيذ أكثر من واجهة واحدة أو فئات فرعية من فئة أساسية أخرى (بافتراض أن هذه ميزة كبيرة جدًا لتلك الفئة الأساسية). في هذه الحالة على وجه الخصوص ، تتمتع الفئات الملموسة لـ Connection و Command وما إلى ذلك لموفري محددين بعلاقة IS A قوية مع تعريفات API المجردة. لا أستطيع حقًا تخيل سيناريو يحتاج فيه بعض المطورين إلى إضافة تنفيذ ملموس لـ IDbConnection أو IConnection إلى فئة فرعية. سيكون السيناريو الوحيد تقريبًا هو الفئات الجديدة التي تشتق فقط لفئة الملخص و "تكرار" نفس التعريف على الواجهة هو عمل أكثر (غير ضروري) لمصمم واجهة برمجة التطبيقات.

هل ترى ميزة أو سيناريو محددًا وملموسًا للحصول على تجريدتين متساويتين؟ متى توفر الواجهة فائدة عملية وحقيقية _ over the class abstract في تصميم API المحدد هذا؟

الميزة الوحيدة التي يمكنني التفكير فيها للواجهات هي التوافق مع الإصدارات السابقة الذي نحتاجه مع القديم لكسر كود التشغيل الفعلي الذي يعتمد على تلك الواجهات. إذا لم يكن لدينا الواجهات القديمة ، فأنا متأكد من أن الفئات المجردة ستكون كافية.

eocampo أنت محق في أن الفئات المجردة ربما توفر تجريدًا

davkean رائحة الشفرة هي أنه في معظم الحالات ، وليس كلها ، تحتاج إلى منفذ لتنفيذ أو وراثة مجموعة أساسية كاملة من الوظائف التي قد لا تكون ذات صلة. أتذكر رؤية تطبيقات IDataReader التي تقرأ من ذاكرة التخزين المؤقت أو في الذاكرة بدلاً من ذلك. لست متأكدًا مما إذا كانت فئة الملخص DbDataReader ستسمح بذلك ، لكن الاسم لا يعني ذلك.

نموذج أفضل الممارسات المتبع في الغالب في الشبكة النقطية تم الكشف عن الواجهات والوراثة من الفئات الأساسية ، أليس كذلك؟

نموذج أفضل الممارسات المتبع في الغالب في الشبكة النقطية تم الكشف عن الواجهات والوراثة من الفئات الأساسية ، أليس كذلك؟

psibernetic حسنا ليس دائما. على سبيل المثال ، هذه التوصية على موقع MSDN لديها أكثر من عقد من الزمان. وهذا المبدأ التوجيهي شائع جدًا من NET Framework 2.0 على الأقل.

هذا أيضًا مرجع جيد للمبادئ التوجيهية لتصميم المكتبات في .Net من الأيام الأولى:

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

على أي حال ، أعتقد أن المناقشة الصعبة هنا تدور حول موضوعين الآن:

أ) تعد الواجهات مخصصة فقط للتوافق مع الإصدارات السابقة أو يمكننا "البدء من نقطة الصفر" (رمز كسر) للسماح بواجهة وتصميم أكثر وضوحًا لواجهة برمجة التطبيقات.
ب) إلى أي مدى يمكن أن نذهب لتصميم حديث ونظيف على حساب عدم توافقه مع إطار عمل .Net الكامل. (التوافق على وجه التحديد بين .Net Core و Full core بشأن الوصول إلى البيانات [ليس أدنى مستوى والتوافق الإلزامي])

من وجهة نظري ، إذا كان لدينا الفئات الأساسية المجردة كعقد أساسي ومفضل ، فيجب أن تتطابق _واجهات_ مع القديمة فقط من أجل التوافق. أفهم أن nvivo قد ذكرت بالفعل أنه بعد .Net 2.0 ، كان العقد الرسمي هو الفئات الأساسية المجردة ، لذلك يمكننا أن نعتقد أن الواجهات لن تحل مشكلة التوافق ولكن mythz و mikeobrien قدموا أيضًا بيانات ثابتة هنا حول تبعية مقدمي الخدمة 1.1 على واجهات.

لوقف البريد العشوائي ومناقشة الموضوعات هنا ، سنحتاج إلى قراءة هذه المحادثة الطويلة مرة أخرى ولا أعرف ما إذا كان بإمكاننا الاتفاق على قائمة الموضوعات المحددة التي نتناولها أو ما إذا كان من الجيد إنشاء موضوعين أو ثلاثة مواضيع جديدة قضايا لكل موضوع محدد. أنا أكثر من الاقتراح الأول لأن هناك الكثير من النقاط الجيدة هنا. ليس لدي فكرة جيدة عن كيفية إعادة تلخيص كل هذه الأمور وإزالة بعض الضوضاء (حتى ضجيجي).

عند الحديث عن الواجهات ، هل هناك خطط لجعل أجزاء من System.Data عامة؟ لطالما أزعجني أن System.Data لم يتم تحديث واجهة برمجة التطبيقات الخاصة به أبدًا إلى ما بعد .NET 1.1 ، مما يترك الأشخاص مضطرين لاستخدام الاختراقات مثل طريقة الامتداد AsEnumerable () للحصول على IEnumerableمن DataTable. لماذا لم تتم ترقية مجموعات مثل DataRowCollection لتنفيذ الواجهات العامة عندما تم تنفيذ كل شيء آخر في إطار العمل عند إصدار 2.0؟

هل سيكون هناك System.Data مع إعادة توجيه النوع فيه؟ أحتاج إلى استخدام ODP.NET ولكن الآن لا يمكنني ذلك.

تم إنشاء dotnet / corefx # 7874

mgravellploeh "Rickasaurus" كانت typeclasses ضمنية في الأفق (لF # على الأقل، غير متأكدة C # .NET أو في عام https://news.ycombinator.com/threads؟id=Rickasaurus). إذا كان الأمر كذلك أنهم قادمون لجميع NET ، فهل سيحل المشكلة؟

أنا لست خبيرًا في Haskell ، لكن ما أفهمه هو أنهم سيسمحون لك بالتثبيت على IDbConnection ، IDbConnectionAsync ، وأي واجهات مشتركة مستقبلية بعد الحقيقة دون كسر المصدر أو التوافق الثنائي ، ودون إجبار مزودي الطرف الثالث على تنفيذ كل شيء. هذا ، مع الاحتفاظ بسهولة الاستهزاء.

هل هذا فهم صحيح؟ إذا كان الأمر كذلك ، فهل هناك أي فرصة لإمكانية وصول هذه الميزة إلى .NET بشكل حقيقي؟