أمثلية الأداء: ربط البيانات.

مقالة
11/01/2010

Windows Presentation Foundation (WPF) ربط البيانات توفر طريقة بسيطة و متناسقة للتطبيقات لتقديم وللتفاعل مع البيانات. يمكن ربط العناصر إلى بيانات من مجموعة متنوعة من مصادر البيانات في صورة كائنات CLR و XML.

يوفر هذا الموضوع توصيات أداء ربط البيانات.

يشتمل هذا الموضوع على الأقسام التالية.

كيفية حل مراجع ربط البيانات
الربط إلى كائنات CLR كبيرة
الربط إلى ItemsSource
ربط IList إلى ItemsControl و ليس IEnumerable
لا تقوم بتحويل كائنات CLR إلى XML فقط لربط البيانات.
موضوعات ذات صلة

كيفية حل مراجع ربط البيانات

قبل مناقشة مشاكل أداء ربط البيانات وهو مفيد استكشاف كيفية مشغّل ربط البيانات Windows Presentation Foundation (WPF) يحل مراجع الكائنات للربط.

المصدر لربط البيانات Windows Presentation Foundation (WPF) يمكن أن يكون أي كائن CLR. يمكنك الربط إلى الخصائص أو الخصائص أو مفهرسات من كائن CLR. يتم حل مراجع الربط باستخدام إما انعكاس Microsoft NET Framewor. أو ICustomTypeDescriptor. فيما يلي ثلاث طرق لحل مراجع الكائنات للربط.

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

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

إذا كان كائن المصدر هو كائن CLR و خاصية المصدر هي خاصية CLR، مشغّل ربط البيانات Windows Presentation Foundation (WPF) يجب أولاً أن يستخدم الانعكاس على كائن المصدر للحصول على TypeDescriptor، ثم يستعلم عن PropertyDescriptor. هذا التسلسل من عمليات الانعكاس يحتمل أن تكون مستهلكة جداً للوقت من منظور الأداء.

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

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

يقارن الجدول أدناه سرعة ربط البيانات لخاصية Text لألف عنصر TextBlock باستخدام هذه الأساليب الثلاثة.

ربط خاصية النص من TextBlock	وقت التقديم(بالملي ثانية)	وقت التقديم --يتضمن الربط (مللي ثانية)
إلى خاصية كائن CLR	115	314
إلى خاصية كائن CLR الذي ينفذ INotifyPropertyChanged	115	305
إلى DependencyProperty من DependencyObject.	90	263

الربط إلى كائنات CLR كبيرة

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

ربط بيانات ألف كائن TextBlock	وقت التقديم(بالملي ثانية)	وقت التقديم --يتضمن الربط (مللي ثانية)
إلى كائن CLR مع ألف خاصية	950	1200
إلى ألف كائن CLR مع خاصية واحدة	115	314

الربط إلى ItemsSource

اطلع على سيناريو حيث لديك كائن CLR List<T> الذي يحتوي على قائمة بالموظفين التي تريدها أن تعرض في ListBox. لإنشاء مراسلات بين كائنين , قم بربط قائمة الموظفين إلى خاصية ItemsSource من ListBox. ومع ذلك، افترض أن لديك موظفاً جديداً ينضم إلى المجموعة الخاصة بك. قد تعتقد أن من أجل إدراج هذا الشخص الجديدة في قيم ListBox المرتبطة بك، ببساطة يمكنك إضافة هذا الشخص إلى قائمة الموظفين و تتوقع التعرف على هذا التغيير من قبل مشغل ربط البيانات تلقائياً. هذا الافتراض سيثبت خطأ; في الحقيقة، هذا التغيير لن ينعكس في ListBox تلقائياً. وهذا لأن كائن CLR List<T> لا يرفع تلقائياً حدث تغيير مجموعة. للحصول على ListBox لانتقاء التغييرات عليك إعادة إنشاء قائمة الموظفين و إعادة ربطها إلى خاصية ItemsSource من ListBox. بينما هذا الحل يعمل, أنه يقدم تأثير أداء كبير جداً. في كل مرة تقوم بإعادة تعيين ItemsSource من ListBox إلى كائن جديد, يقوم ListBox أولاً بطرح بعيداً العناصر السابقة الخاصة به وإعادة إنشاء القائمة الكاملة الخاصة به. يتم تكبير تأثير الأداء إذا كان ListBox الخاص بك يُعين إلى DataTemplate مركب.

حلاً فعال جداً لهذه المشكلة هو التأكد من جعل قائمة الموظف الخاصة بك ObservableCollection<T>. كائن ObservableCollection<T> يرفع إعلام تغيير الذي يمكن تلقيه من قبل مشغّل ربط البيانات. الحدث يضيف أو يزيل عنصر من ItemsControl دون الحاجة إلى إعادة إنشاء القائمة بأكملها.

الجدول الموجود بالأدنى يعرض الوقت المستغرق في تحديث ListBox ( مع إيقاف تشغيل الوضع الظاهري UI ) عند إضافة عنصر واحد. يمثل الرقم في الصف الأول الوقت المنقضي عند ربط كائن CLR List<T> إلى ItemsSource الخاصة بعنصر ListBox. يمثل الرقم في الصف الثاني الوقت المنقضي عند ربط ObservableCollection<T> إلى ItemsSource الخاصة بعنصر ListBox. لاحظ توفير وقت باستخدام استراتيجية ربط البيانات ObservableCollection<T>.

ربط بيانات ItemsSource	وقت تحديث عنصر واحد (مللي ثانية)
إلى كائن CLR List<T>	1656
إلى ObservableCollection<T>	20

ربط IList إلى ItemsControl و ليس IEnumerable

إذا كان لديك اختيار بين ربط IList<T> أو IEnumerable إلى كائن ItemsControl ، اختر كائن IList<T>. ربط IEnumerable إلى ItemsControl يفرض على WPF إنشاء مجمّع كائن IList<T> مما يعني أن الأداء الخاص بك يتأثر بواسطة مقدار الحمل غير الضروري من الكائن الثاني.

لا تقوم بتحويل كائنات CLR إلى XML فقط لربط البيانات.

WPF يسمح لك بربط بيانات إلى محتوي XML; مع ذلك، ربط البيانات إلى محتوي XML أبطأ من ربط البيانات إلى كائنات CLR. لا تقم بتحويل بيانات كائن CLR إلى XML إذا كان الهدف الوحيد هو ربط البيانات.