النماذج والتحقق من صحة البيانات

النموذج هو المكان الذي يفقد فيه التطبيق السيطرة. فكل ما يصل عبر طلب POST هو سلسلة نصية أنتجها شخص آخر: مستخدم مستعجل، أو متصفح يملأ حقلًا تلقائيًا، أو سكربت يتجاوز الصفحة. فقد يحتوي حقل «سنة النشر» على 1985، أو mille neuf cent، أو قيمة فارغة، أو ثلاثمئة حرف.

لذلك فالسؤال ليس هل ستكون البيانات غير صالحة، بل أين يقرر التطبيق اكتشاف ذلك. والتصرف الطبيعي، وهو التحقق في بداية دالة المتحكم، ينتج شيفرة تكدّس عبارات if، وتخلط قواعد العمل بالبنية التحتية للويب، وتكرر عمليات التحقق نفسها في كل موضع يُستقبل فيه الكائن. وبعد بضع شاشات، يصبح نموذجان يتعاملان مع الكائن نفسه لا يتحققان منه بالطريقة ذاتها.

أما التصرف الآخر، وهو الاعتماد على تحقق المتصفح عبر required وtype="number"، فمريح لكنه خاطئ. فهذه السمات تحسّن التجربة لكنها لا تحمي شيئًا: إذ تُقيَّم عند العميل الذي يستطيع تعطيلها، وأي أمر curl مُحكم الصياغة يتجاهلها تمامًا. التحقق من جهة العميل مجرد وسيلة راحة، أما التحقق من جهة الخادم فهو ضمانة.

يحل Spring MVC المشكلتين معًا. فـالربط (liaison) يحوّل معاملات الطلب ويسندها تلقائيًا إلى خصائص كائن Java. والتحقق التصريحي يُلحق القواعد بالكائن نفسه على شكل annotations، بحيث تنطبق في كل موضع يُستقبل فيه. ولا يبقى على المتحكم سوى أن يسأل: «هل هذا الكائن مقبول؟»