إعادة استخدام التحقق من صحة السمات في العرف ViewModels

Question

عندما بدأت باستخدام xVal من أجل التحقق من جانب العميل ، كنت فقط تنفيذ الإجراءات والأساليب التي تستخدم المجال نموذج الكائنات كما viewmodel أو جزءا لا يتجزأ من الحالات من تلك الكائنات في viewmodel.

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

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

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

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

هل هناك أي أنيقة الحل لهذا ؟ لقد تم النظر في القرصنة xVal المصدرية ، ولكن ربما هناك طريقة أخرى يجب التغاضي عنها حتى الآن.

شكرا

أدريان

تحرير: مع وصول ASP.NET MVC 2, هذه ليست فقط مشكلة تتعلق التحقق من صحة السمات بعد الآن, ولكنه ينطبق أيضا على محرر وعرض الصفات.

Answer 1

هذا هو الجوهر السبب المدخلات الخاصة بك شاشات لا ينبغي أن يكون محكم بالإضافة إلى النموذج الخاص بك.هذا السؤال في الحقيقة ينبثق هنا على MVC الوسم حوالي 3-4 مرات في الشهر.كنت مغفل إذا كان بإمكاني العثور على السؤال السابق و بعض التعليق المناقشة هنا هو إثارة للاهتمام.;)

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

الخيارات للحصول على جميع أنحاء هذه كلها دون المستوى الأمثل.لقد عملت على هذه المشكلة لمدة 3 مشاريع الآن وتنفيذ الحلول التالية لم تكن نظيفة و عادة ما تكون محبطة.أنا أحاول أن العملية و ننسى كل DDD/db/نموذج/hotnessofthemonth المناقشات الجميع هو وجود.

1) عرض متعددة النماذج وجود viewmodels التي هي تقريبا نفس ينتهك الجافة الرئيسية ولكن أشعر تكاليف هذا النهج منخفضة حقا.عادة ما تنتهك الجافة الامبير حتى تكاليف الصيانة ولكن IMHO تكاليف هذه هي الدنيا لا تساوي الكثير.من الناحية النظرية لا تغيير كيفية الحد الأقصى لعدد الأحرف في حقل اسم العائلة يمكن أن يكون في كثير من الأحيان.

2) ديناميكية البيانات الوصفية هناك السنانير في MVC 2 توفير البيانات الوصفية الخاصة بك على نموذج.مع هذا النهج يمكن أن يكون لديك كل ما تبذلونه باستخدام توفير البيانات الوصفية استبعاد بعض المجالات على أساس الحالية HTTPRequest وبالتالي عمل وحدة تحكم.لقد استعملت هذه التقنية لبناء قاعدة بيانات مدفوعة أذونات النظام الذي يذهب إلى DB و يحكي فئة فرعية من DataAnnotationsMetadataProvider استبعاد خصائص القيم المخزنة في قاعدة البيانات.

هذا الأسلوب هو عمل عظيم الصراف الآلي ولكن المشكلة الوحيدة هي مع التحقق من صحة UpdateModel().لحل هذه المشكلة أنشأنا SmartUpdateModel() الأسلوب الذي يذهب أيضا إلى قاعدة البيانات تلقائيا استبعاد string[] مجموعة بحيث أن أي غير permissisable الحقول ليست من صحتها.نحن بالطبع مؤقتا هذا لأسباب الأداء لذلك ليس سيئا.

فقط أريد أن أؤكد مجددا أننا المستخدمة [ValidationAttributes] على نماذج ثم إنه يبحث مع القواعد الجديدة في وقت التشغيل.كانت النتيجة النهائية أن [Required] المستخدم.اسم العائلة المجال لم يكن من صحتها إذا كان المستخدم لم يكن لديك إذن للوصول إلى ذلك.

3) مجنون واجهة ديناميكية الوكيل شيء آخر تقنية حاولت استخدام واجهات ViewModels.النتيجة النهائية كانت لدي المستخدم الكائن الذي ورثت من واجهات مثل IAdminEdit و IUserRegistration.IAdminEdit و IUserRegistration أن كلاهما يحتوي على DataAnnotation السمات التي يؤديها كل سياق محدد التحقق من صحة كلمة مرور الملكية مع الواجهات.

وهذا يتطلب بعض hackery و كان أكثر ممارسة أكاديمية من أي شيء آخر.المشكلة مع 2 و 3 هو أن UpdateModel و DataAnnotationsAttribute مزود بحاجة إلى أن تكون مخصصة لتكون على بينة من هذه التقنية.

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

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

Answer 2

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

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

Answer 3

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

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

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

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

Answer 4

أنا لا أعرف كيف سيلعب من أجل التحقق من جانب العميل ، ولكن إذا جزئية التحقق من صحة هو المشكلة يمكنك تعديل DataAnnotationsValidationRunner ناقش هنا أن تأخذ في IEnumerable<string> قائمة أسماء الملكية على النحو التالي:

public static class DataAnnotationsValidationRunner
{
     public static IEnumerable<ErrorInfo> GetErrors(object instance, IEnumerable<string> fieldsToValidate)
     {
           return from prop in TypeDescriptor.GetProperties(instance).Cast<PropertyDescriptor>().Where(p => fieldsToValidate.Contains(p.Name))
                  from attribute in prop.Attributes.OfType<ValidationAttribute>()
                  where !attribute.IsValid(prop.GetValue(instance))
                  select new ErrorInfo(prop.Name, attribute.FormatErrorMessage(string.Empty), instance);
     }
}

Answer 5

أنا ستعمل خطر downvotes و الدولة التي لا يوجد فائدة ViewModels (في ASP.NET MVC) ، وخاصة بالنظر إلى النفقات العامة من إنشاء و الحفاظ عليها.إذا كانت الفكرة هي فصل من المجال الذي لا يمكن الدفاع عنه.واجهة المستخدم تنفصل عن مجال ليس UI هذا المجال.واجهة المستخدم يجب أن تعتمد على المجال لذا إما أن يكون وجهات النظر الخاصة بك/الأعمال بالإضافة إلى نموذج المجال أو ViewModel إدارة المنطق بالإضافة إلى نموذج المجال.العمارة الحجة وهكذا الصورية.

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

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