تمرير أو الحصول على قيمة من Parent ViewModel وصولاً إلى Sub-Viewmodel؟

Question

أنا أستخدم إطار Light MVVM وكذلك الوحدة لـ DI. لدي بعض الآراء المتداخلة ، كل ملزمة إلى ViewModel المقابلة. ترتبط ViewModels بنص التحكم في كل طريقة عرض DataContext عبر فكرة ViewModellocator التي وضعتها Laurent Bugnion في ضوء MVVM. يسمح ذلك بإيجاد ViewModels عبر مورد ثابت والتحكم في عمر ViewModels عبر إطار حقن التبعية ، في هذه الحالة. كما يسمح بمزيج التعبير لرؤية كل شيء فيما يتعلق بـ ViewModels وكيفية ربطها.

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

لذا ، إليك مثال على كيفية تفاعل ViewModels عبر المراسلة. لقد حصلت على طريقة عرض للوالدين تحتوي على قاعدة بيانات Combobox إلى ObservableCollection في ViewModel الخاص بها. يتم ربط Combobox's SelectionItem أيضًا (في اتجاهين) إلى خاصية على ViewModel. عندما يتغير اختيار Combobox ، فإن هذا هو تشغيل التحديثات في طرق عرض أخرى ووجهات نظر فرعية. حاليًا أقوم بإنجاز هذا عبر نظام المراسلة الموجود في MVVM Light.

لذلك أنا أتساءل ما هي أفضل الممارسات للحصول على معلومات من ViewModel إلى آخر؟ في هذه الحالة ، فإن ما أحتاجه للانتقال إلى Sub-Viewmodels هو في الأساس دليل مستخدم يمثل المستخدم المسجل حاليًا. ستعرف عرض الوالدين الأعلى (جيدًا ، ViewModel) هذه المعلومات ، لكنني لست متأكدًا من كيفية الحصول عليها في موزود العرض الفرعية.

بعض الأساليب الممكنة التي يمكنني التفكير فيها:

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

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

Answer 1

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

لقد أجريت محادثة على Twitter مع بعض الأسماء المعروفة في هذا الفضاء (Glenn Block و John Papa و Rob Eisenberg). اقترحوا عددًا من الأشياء مثل نمط الزائر ، لكنني لم أكن متأكدًا من أن ذلك سيعمل بشكل جيد بدون تسلسل هرمي لـ VMs. قد يكون هذا لأن تصميمي كان إلى حد كبير عرضًا أولاً ، بدلاً من نهج ViewModel الأول. هناك اقتراح آخر قد يكون عمليًا هو تعديل استخدام ViewModellocator وحقن التبعية لتشمل القدرة على تمرير قيم البيانات إلى VMs الفرعية في وقت الإنشاء. واجهت مشكلة صغيرة في تصورها بسبب الطبيعة الثابتة لـ VML ، وقررت أن حل طلب الرسائل الذي توصلت إليه سيكون أكثر مباشرة وبساطة في الوقت الحالي. من المحتمل أن أضطر إلى إعادة التفكير في الحل إذا انتهى الأمر بوجود الكثير من البيانات التي تقع في هذا الموقف.

Answer 2

لقد رأيت أساسا نهجين لهذا. للاتصالات العامة عبر VM ، يعمل نمط مجمع الأحداث بشكل رائع.

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

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

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

بلدي .02 دولار جلين