MVVM: هل يجب أن يكشف كائن VM كائن م مباشرة، أو فقط من خلال الحصول على تفتيش إلى M's Getters؟

Question

أفضل طريقة لشرحها مع مثال:

هذا هو النموذج

public class Person 
{
    public int age;
    public string name;
}

هذا هو نموذج الرأي

public class PersonVM
{    
}

سؤالي هو:
هل يجب أن يعرض VM الشخص إلى قالب البيانات أو يغليف خصائص النموذج بممتلكاته الخاصة؟

Answer 1

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

class PersonModel {
    public string Name { get; set; }
}

class PersonViewModel {
    private PersonModel Person { get; set;}
    public string Name { get { return this.Person.Name; } }
    public bool IsSelected { get; set; } // example of state exposed by view model

    public PersonViewModel(PersonModel person) {
        this.Person = person;
    }
}

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

Answer 2

لا يوجد اتفاق عام حول هذا السؤال. على سبيل المثال، كانت واحدة من الأسئلة المفتوحة حول MVVM صاغها جنح الجناح هنا:

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

المزايا الرئيسية لعدم تعريض النموذج مباشرة في VM هي:

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

• يمكنك حقن Funcionality الأخرى المتعلقة بواجهة المستخدم، مثل رسائل التحقق من صحة البيانات, التراجع عن إعادته,..

السلبيات هي:

• سيتعين عليك تكرار الكثير من التعليمات البرمجية لفضح جميع خصائص النماذج في ViewModel.

• إذا قمت بربط عنصر تحكم الرؤية في خاصية ViewModels، فسترسل الأحداث المستعملة من ViewModel. ولكن ماذا يحدث إذا تغيرت خصائص النماذج من مصدر آخر مختلف عن Setter ViewModel؟ ثم يجب أن يخطر ViewModel حتى تنتهي ب 2 OnPropertychanged، واحدة في النموذج وواحد في ViewModel ... معقدة للغاية!

لذلك بالنسبة لي الإجابة الصحيحة هي: ذلك يعتمد على متطلباتك.

Answer 3

تم اقتراح حل روبرت مكارتر مثيرا للاهتمام في حجم MSDN المجلد 25.

http://msdn.microsoft.com/en-us/magazine/ff798279.aspx.

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

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

Answer 4

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