مكتبة عميل قاعدة بيانات مرنة مع إطار عمل الكيان

ينطبق على: قاعدة بيانات Azure SQL

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

تحميل نموذج التعليمات البرمجية وتشغيله

لتنزيل التعليمات البرمجية لهذه المقالة:

• نسخة Visual Studio عام 2012 أو ما بعدها مطلوبة.
• تحميل أدوات DB مرنة لـ Azure SQL - نموذج تكامل إطار الكيان. قم بإلغاء ضغط العينة إلى موقع من اختيارك.
• بدء Visual Studio.
• في Visual Studio، حدد ملف File -> Open Project/Solution.
• في مربع الحوار Open Project انتقل إلى النموذج الذي قمت بتنزيله وحدد EntityFrameworkCodeFirst.sln لفتح العينة.

لتشغيل النموذج، تحتاج إلى إنشاء ثلاث قواعد بيانات فارغة في قاعدة بيانات Azure SQL:

• قاعدة بيانات Shard Map Manager
• قاعدة بيانات Shard 1
• قاعدة بيانات Shard 2

بمجرد إنشاء قواعد البيانات هذه، قم بتعبئة أصحاب الأماكن في Program.cs باسم الخادم وأسماء قواعد البيانات وبيانات الاعتماد الخاصة بك للاتصال بقواعد البيانات. افتح ملف الحل في Visual Studio. يقوم برنامج Visual Studio بتنزيل حزم NuGet المطلوبة لمكتبة عميل قاعدة البيانات المرنة وإطار عمل الكيان ومعالجة الخطأ العابر كجزء من عملية الإنشاء. تأكد من تمكين استعادة حزم NuGet للحل الخاص بك. يمكنك تمكين هذا الإعداد بالنقر بزر الماوس الأيمن فوق ملف الحل في خاصية مستكشف الحلول في Visual Studio.

سير عمل إطار الكيان

يعتمد مطورو إطار الكيان على أحد مهام سير العمل الأربعة التالية لإنشاء التطبيقات وضمان الاستمرارية لكائنات التطبيق:

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

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

افتراضات أدوات قاعدة البيانات المرنة

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

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

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

المتطلبات

عند العمل مع كل من مكتبة عميل قاعدة البيانات المرنة وإطار عمل كيان APIs، فسوف تحتاج إلى الاحتفاظ الخصائص التالية:

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

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

التوجيه المعتمد على البيانات باستخدام EF DbContext

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

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

لدمج DbContexts مع توجيه معتمد على البيانات للتوسيع:

1. أنشئ اتصالات قاعدة بيانات فعلية من خلال واجهات عميل قاعدة بيانات مرنة لمدير مخطط القطع.
2. غلف الاتصال مع الفئة الفرعية DbContext
3. مرر الاتصال لأسفل إلى فئات DbContext الأساسية لضمان حدوث جميع المعالجة على EF أيضاً.

يوضح المثال التالي من التعليمات البرمجية هذا الأسلوب. (هذا الرمز موجود أيضاً في مشروع Visual Studio المصاحب)

public class ElasticScaleContext<T> : DbContext
{
public DbSet<Blog> Blogs { get; set; }
...

    // C'tor for data-dependent routing. This call opens a validated connection
    // routed to the proper shard by the shard map manager.
    // Note that the base class c'tor call fails for an open connection
    // if migrations need to be done and SQL credentials are used. This is the reason for the
    // separation of c'tors into the data-dependent routing case (this c'tor) and the internal c'tor for new shards.
    public ElasticScaleContext(ShardMap shardMap, T shardingKey, string connectionStr)
        : base(CreateDDRConnection(shardMap, shardingKey, connectionStr),
        true /* contextOwnsConnection */)
    {
    }

    // Only static methods are allowed in calls into base class c'tors.
    private static DbConnection CreateDDRConnection(
    ShardMap shardMap,
    T shardingKey,
    string connectionStr)
    {
        // No initialization
        Database.SetInitializer<ElasticScaleContext<T>>(null);

        // Ask shard map to broker a validated connection for the given key
        SqlConnection conn = shardMap.OpenConnectionForKey<T>
                            (shardingKey, connectionStr, ConnectionOptions.Validate);
        return conn;
    }

النقاط الرئيسية

• منشئ جديد يستبدل المنشئ الافتراضي في الفئة الفرعية DbContext

• المنشئ الجديد يأخذ الوسيطات المطلوبة للتوجيه تعتمد على البيانات من خلال مكتبة عميل قاعدة بيانات مرنة:

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

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

  • ويستخدم استدعاء OpenConnectionForKey واجهات عميل قاعدة البيانات المرنة على مخطط القطع لإنشاء اتصال مفتوح.
  • خريطة القطع يخلق الاتصال المفتوح إلى المقطع الذي يحمل shardlet لمفتاح القطع المقدم.
  • يتم تمرير هذا الاتصال المفتوح مرة أخرى إلى منشئ فئة أساسية DbContext للإشارة إلى أن هذا الاتصال هو لاستخدامها من قبل EF بدلاً من السماح لـ EF بإنشاء اتصال جديد تلقائياً. بهذه الطريقة تم وضع علامة للاتصال بواسطة واجهة برمجة تطبيقات عميل قاعدة البيانات المرنة بحيث يمكن أن تضمن التناسق تحت عمليات إدارة مخطط القطع.

استخدم المنشئ الجديد لفئة DbContext الفرعية بدلاً من المنشئ الافتراضي في التعليمات البرمجية. وفيما يلي مثال على ذلك:

// Create and save a new blog.

Console.Write("Enter a name for a new blog: ");
var name = Console.ReadLine();

using (var db = new ElasticScaleContext<int>(
                        sharding.ShardMap,  
                        tenantId1,  
                        connStrBldr.ConnectionString))
{
    var blog = new Blog { Name = name };
    db.Blogs.Add(blog);
    db.SaveChanges();

    // Display all Blogs for tenant 1
    var query = from b in db.Blogs
                orderby b.Name
                select b;
    …
}

المنشئ الجديد يفتح الاتصال إلى المقطع الذي يحتوي على البيانات للشاردليت التي تم تعريفها من قبل قيمة tenantid1. تبقى التعليمات البرمجية في الكتلة المستخدمة دون تغيير للوصول إلى DbSet للمدونات باستخدام EF على المقطع لـ tenantid1. هذا يغير دلالات التعليمات البرمجية في الكتلة المستخدمة بحيث يتم الآن وضع جميع عمليات قاعدة البيانات في مقطع واحد الذي يوجد به tenantid1. على سبيل المثال، فإن استعلام LINQ عبر المدونات DbSet سيعود فقط بالمدونات المخزنة على المقطع الحالي، ولكن ليس تلك المخزنة على مقاطع أخرى.

معالجة الأخطاء العرضية

قام فريق Microsoft Patterns & Practices بنشر Transient Fault Handling Application Block. يتم استخدام المكتبة مع مكتبة العميل المرنة بالاشتراك مع EF. ومع ذلك، تأكد من أن أي استثناء عارض يرجع إلى مكان حيث يمكنك التأكد من أنه يتم استخدام المنشئ الجديد بعد خطأ عارض بحيث يتم إجراء أي محاولة اتصال جديدة باستخدام المنشئات التي عدلتها. وإلا، يكون الاتصال بالمقطع الصحيح غير مضمون، ولا توجد أي ضمانات بأنه يتم الاحتفاظ الاتصال عندما تحدث تغييرات على مخطط القطع.

يوضح نموذج التعليمات البرمجية التالي كيفية استخدام نهج إعادة محاولة SQL حول منشئات الفئة الفرعية DbContext الجديدة:

SqlDatabaseUtils.SqlRetryPolicy.ExecuteAction(() =>
{
    using (var db = new ElasticScaleContext<int>(
                            sharding.ShardMap,  
                            tenantId1,  
                            connStrBldr.ConnectionString))
        {
                var blog = new Blog { Name = name };
                db.Blogs.Add(blog);
                db.SaveChanges();
        …
        }
    });

يتم تعريف SqlDatabaseUtils.SqlRetryPolicy في التعليمات البرمجية أعلاه كـ SqlDatabaseTransientErrorDetectionStrategy مع 10 مرات لإعادة المحاولة و5 ثوان وقت الانتظار بين كل محاولة والأخرى. يشبه هذا النهج إرشادات EF والمعاملات التي بدأها المستخدم (راجع قيود إعادة محاولة تنفيذ إستراتيجيات (EF6 فصاعداً). تتطلب كلتا الحالتين أن يتحكم برنامج التطبيق في النطاق الذي يرجع إليه الاستثناء العارض: إما إعادة فتح المعاملة، أو (كما هو موضح) إعادة إنشاء السياق من المنشئ المناسب الذي يستخدم مكتبة عميل قاعدة البيانات المرنة.

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

إعادة كتابة المنشئ

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

المنشئ الحالي	المنشئ المعاد كتابته للبيانات	المنشئ الأساسي	ملاحظات
MyContext()	ElasticScaleContext(ShardMap, TKey)	DbContext(DbConnection, bool)	يجب أن يكون الاتصال وظيفة مخطط القطع ومفتاح التوجيه المعتمد على البيانات. تحتاج إلى تمرير إنشاء اتصال تلقائي بواسطة EF واستخدام مخطط القطع بدلاً من ذلك للتوسط في الاتصال.
MyContext(string)	ElasticScaleContext(ShardMap, TKey)	DbContext(DbConnection, bool)	الاتصال هو وظيفة مخطط القطع ومفتاح التوجيه المعتمد على البيانات. لا يعمل اسم قاعدة بيانات ثابت أو سلسلة اتصال عندما تخطي التدقيق بواسطة مخطط القطع.
MyContext (DbCompiledModel)	ElasticScaleContext(ShardMap, TKey)	DbContext (DbConnection، DbCompiledModel، بول)	يتم إنشاء الاتصال للمخطط القطعي المقدم ومفتاح القطع مع الطراز المقدم. يتم تمرير النموذج المجمع إلى القاعدة الأساسية.
MyContext(DbConnection, bool)	ElasticScaleContext(ShardMap, TKey, bool)	DbContext(DbConnection, bool)	يجب استنتاج الاتصال من مخطط القطع والمفتاح. لا يمكن توفيره كمدخل (إلا إذا كان هذا الإدخال يستخدم بالفعل مخطط القطع والمفتاح). يتم تمرير الاتصال المنطقي.
MyContext(string, DbCompiledModel)	ElasticScaleContext(ShardMap, TKey)	DbContext (DbConnection، DbCompiledModel، بول)	يجب استنتاج الاتصال من مخطط القطع والمفتاح. لا يمكن توفيره كمدخل (إلا إذا كان هذا الإدخال يستخدم مخطط القطع والمفتاح). يتم تمرير النموذج المجمع.
MyContext(ObjectContext, bool)	ElasticScaleContext(ShardMap, TKey, ObjectContext, bool)	MyContext(ObjectContext, bool)	المنشئ الجديد يحتاج إلى التأكد من أن أي اتصال في ObjectContext يتم تمريره كمدخل، يتم إعادة توجيهه إلى اتصال مدار بمقياس مرن. مناقشة مفصلة حول ObjectContexts ليست في نطاق هذا المستند.
MyContext(DbConnection, DbCompiledModel, bool)	ElasticScaleContext(ShardMap, TKey, DbCompiledModel, bool)	DbContext(DbConnection, DbCompiledModel, bool);	يجب استنتاج الاتصال من مخطط القطع والمفتاح. لا يمكن توفير الاتصال كمدخل (إلا إذا كان هذا الإدخال يستخدم مخطط القطع والمفتاح بالفعل). يتم تمرير الاتصال النموذجي والمنطقي إلى منشئ فئة أساسية.

نشر مخطط القطع من خلال عمليات ترحيل EF

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

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

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

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

مع هذه المتطلبات الأساسية في مكانها، يمكنك إنشاء SqlConnection عادي غير مفتوح لبدء عمليات الترحيل EF لنشر المخطط. يوضح نموذج التعليمات البرمجية التالي هذا الأسلوب.

// Enter a new shard - i.e. an empty database - to the shard map, allocate a first tenant to it  
// and kick off EF initialization of the database to deploy schema

public void RegisterNewShard(string server, string database, string connStr, int key)
{

    Shard shard = this.ShardMap.CreateShard(new ShardLocation(server, database));

    SqlConnectionStringBuilder connStrBldr = new SqlConnectionStringBuilder(connStr);
    connStrBldr.DataSource = server;
    connStrBldr.InitialCatalog = database;

    // Go into a DbContext to trigger migrations and schema deployment for the new shard.
    // This requires an un-opened connection.
    using (var db = new ElasticScaleContext<int>(connStrBldr.ConnectionString))
    {
        // Run a query to engage EF migrations
        (from b in db.Blogs
            select b).Count();
    }

    // Register the mapping of the tenant to the shard in the shard map.
    // After this step, data-dependent routing on the shard map can be used

    this.ShardMap.CreatePointMapping(key, shard);
}

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

// C'tor to deploy schema and migrations to a new shard
protected internal ElasticScaleContext(string connectionString)
    : base(SetInitializerForConnection(connectionString))
{
}

// Only static methods are allowed in calls into base class c'tors
private static string SetInitializerForConnection(string connectionString)
{
    // You want existence checks so that the schema can get deployed
    Database.SetInitializer<ElasticScaleContext<T>>(
new CreateDatabaseIfNotExists<ElasticScaleContext<T>>());

    return connectionString;
}

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

التقييدات

تنطوي النهج المبينة في هذه الوثيقة على بعض التقييدات:

• تحتاج تطبيقات EF التي تستخدم LocalDb أولاً إلى الترحيل إلى قاعدة بيانات SQL Server عادية قبل استخدام مكتبة عميل قاعدة بيانات مرنة. توسيع نطاق تطبيق من خلال القطع مع مقياس مرن غير ممكن مع LocalDb. لاحظ أنه لا يزال بإمكان التطوير استخدام LocalDb.
• أي تغييرات على التطبيق الذي يعني تغييرات مخطط قاعدة البيانات تحتاج إلى المرور بتجهيزات EF على جميع القطع. لا يوضح نموذج التعليمات البرمجية لهذا المستند كيفية القيام بذلك. خذ بعين الاعتبار استخدام Update-Database مع مَعلمة ConnectionString للإعادة عبر جميع القطع؛ أو استخراج النص البرمجي T-SQL للترحيل المعلق باستخدام Update-Database مع الخيار -Script وتطبيق النص البرمجي T-SQL إلى القطع الخاصة بك.
• وبالنظر إلى الطلب، يفترض أن جميع معالجة قاعدة البيانات الخاصة به موجودة في قطعة واحدة كما يحددها مفتاح القطع الذي يوفره الطلب. ومع ذلك، هذا الافتراض ليس دوماً صحيحاً. على سبيل المثال، عندما لا يكون من الممكن جعل مفتاح القطع متوفراً. لمعالجة هذا، توفر مكتبة العميل فئة MultiShardQuery التي تنفذ تجريد اتصال للاستعلام عبر عدة قطع. تعلم استخدام MultiShardQuery بالاشتراك مع EF خارج نطاق هذا المستند

الختام

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

الموارد الإضافية

ألم تستخدم أدوات قاعدة بيانات مرنة بعد؟ تحقق من ⁧⁩دليل بدء التشغيل⁩. في حالة وجود أسئلة، تواصل معنا على Microsoft Q&A وهي صفحة الأسئلة حول SQL Database ولطلبات الميزات، أضف أفكاراً جديدة أو صوّت للأفكار الموجودة في منتدى ملاحظات SQL Database.