أين تفعل التحقق من صحة الخاص بك؟النموذج أو وحدة التحكم أو العرض

Question

أين يمكنك وضع التحقق من صحة إدخال المستخدم في تطبيق نموذج الويب؟

1. منظر:جانب عميل جافا سكريبت
2. مراقب:لغة جانب الخادم (C#...)
3. نموذج:قاعدة البيانات (الإجراءات المخزنة أو التبعيات)

أعتقد أن هناك التحقق من الصحة مطلوبًا لكل مستوى:

1. هل قام المستخدم بإدخال قيمة معقولة
   • هي التواريخ تواريخ فعلية، هي أرقام في الواقع أرقام ...
2. قم بإجراء كافة الفحوصات في 1.مرة أخرى بالإضافة إلى عمليات التحقق من الهجمات الضارة (IE XSS أو حقن SQL)
   • الشيكات التي تم إجراؤها في 1.تهدف بشكل أساسي إلى تجنب رحلة الخادم ذهابًا وإيابًا عندما يرتكب المستخدم خطأً.
   • وبما أنها تتم من جانب العميل في جافا سكريبت، فلا يمكنك الوثوق في تشغيلها.سيؤدي التحقق من صحة هذه القيم مرة أخرى إلى إيقاف بعض الهجمات الضارة.
3. هل تم استيفاء التبعيات (على سبيل المثال.هل أضاف المستخدم تعليقًا على سؤال صالح)
   • الواجهة الجيدة تجعل من الصعب جدًا انتهاكها.إذا تم اكتشاف شيء ما هنا، فقد حدث خطأ ما.

[مستوحاة من هذا الرد]

Answer 1

لقد قمت بالتحقق من جميع المستويات، ولكن أود أن أشير إلى خدعة التحقق التي أستخدمها.

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

يبدو أن هذا فن مفقود لدى معظم مبرمجي الويب.

Answer 2

التحقق من الصحة في النموذج، إجراءات تلقائية اختيارية في واجهة المستخدم التي تأخذ تلميحاتها من النموذج وتحسن تجربة المستخدم.

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

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

Answer 3

يمكن إجراء التحقق من الصحة في جميع الطبقات.

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

ثم لديك التحقق من صحة طبقة DAO - هل توجد بيانات كافية في النموذج للاستمرار (لتلبية القيود غير الخالية، وما إلى ذلك) وما إلى ذلك.يمكنك أيضًا التحقق من القيود في قاعدة البيانات (الحالة في ('N'، 'A'، 'S'، 'D') وما إلى ذلك).

Answer 4

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

داخل TDG، سأقوم بتنفيذ منطق الأعمال وعمليات التحقق من الصحة، مثل:

1. هل اسم المستخدم فارغ
2. هو اسم المستخدم> 30 حرفا
3. إذا كان السجل غير موجود، قم بإرجاع الخطأ

مع تزايد تعقيد تطبيقي، بدأت أدرك أنه يمكن إجراء الكثير من عمليات التحقق من جانب العميل، باستخدام JavaScript.لذلك قمت بإعادة هيكلة معظم منطق التحقق في JS وقمت بتنظيف النماذج الخاصة بي.

ثم أدركت أن التحقق من جانب الخادم (وليس التصفية/الهروب - وهو ما أعتبره مختلفًا) يجب أن يتم على الخادم أيضًا وفقط من جانب العميل كزينة على الكعكة.

لذلك عاد منطق التحقق من الصحة، عندما أدركت مرة أخرى، أنه ربما كان هناك فرق واضح بين التحقق من صحة/تأكيد INPUT وقواعد/منطق العمل.

بشكل أساسي، إذا كان من الممكن القيام بذلك في جانب العميل من التطبيق (باستخدام JS) فأنا أعتبر هذا بمثابة التحقق من صحة INPUT... إذا كان يجب أن يتم ذلك بواسطة النموذج (هل هذا السجل موجود بالفعل، وما إلى ذلك؟) فسأعتبر ذلك منطق الأعمال.الأمر المربك هو أن كلاهما يحمي سلامة نموذج البيانات.

إذا لم تقم بالتحقق من صحة طول اسم المستخدم، فما الذي يمنع الأشخاص من إنشاء اسم مستخدم مكون من حرف واحد؟

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

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

ما هي القوى التي تدفعك في أي من الاتجاهين هي في الواقع الرأي الشخصي والمتطلبات والخبرات وما إلى ذلك ...

موضوع مشوق :)

Answer 5

تصديق يجب يتم ذلك في وحدة التحكم - فهو المكان الوحيد الذي يضمن السلامة والاستجابة.

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

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

Answer 6

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

Answer 7

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

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

Answer 8

هممم، لست متأكدا.كنت سأقول المراقب المالي حتى أقرأ هذا المقال:وحدات تحكم نحيفة، نماذج سمينة

http://blog.astrumfutura.com/archives/373-The-M-in-MVC-When-Models-are-Misunderstood-and-Unappreciated.html

Answer 9

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

عمليات التحقق من جانب العميل هي عمليات ثانوية، تم إجراؤها للتو لبناء نسخة خفيفة الوزن التحقق من صحة الإدخال, ، ولكن التحقق من جانب الخادم هو مطلوب دائما.لا يمكنك الوثوق مطلقًا في مدخلات المستخدم ;)

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

Answer 10

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

ولكن، كما قلت، التحقق بسيط من وجهة النظر من حيث السرعة والسهولة.