مقدمة
نمط MVC و DispatcherServlet قبل أي توصيف (annotation).
مقدمة في Spring MVC
كتابة تطبيق ويب بلغة Java دون إطار عمل تمرين مفيد، ولا يكرره أحد مرتين. عليك أن تعلن عن servlet لكل شاشة، وأن تقرأ المعاملات يدويًا من HttpServletRequest، وأن تحوّلها من سلاسل نصية، وأن تتحقق من أنها ليست غائبة، وأن تقرر ما يجب فعله عند فشل التحويل، وأن تختار رمز حالة، ثم تكتب HTML حرفًا حرفًا في تدفق الخرج. فيغرق الكود المهني، أي الأسطر الثلاثة التي تهم فعلًا، في هذه السباكة، وتُعاد كتابة هذه السباكة عند كل شاشة.
المشكلة ليست في كمية الكود، بل في أن هذا الكود المتكرر هو كود قرارات. فكل servlet تقرر وحدها كيف تفسّر الطلب، وكيف تُبلغ عن خطأ، وكيف تنتج استجابتها. وبعد ثلاثين شاشة يحتوي التطبيق على ثلاثين اصطلاحًا متباينة قليلًا، ويصبح أي تغيير شامل، كإضافة تتبّع أو فرض صيغة تاريخ أو معالجة الأخطاء بشكل موحّد، بحثًا عن كنز في ثلاثين ملفًا.
يعالج Spring MVC ذلك بقلب المعادلة: بدلًا من ترك كل شاشة تتدبر أمرها، تستقبل servlet واحدة جميع طلبات التطبيق وتنسّق معالجتها. هذه الـ servlet لا تعرف شيئًا عن منطقك المهني؛ كل ما تعرفه هو تحديد قطعة الكود المسؤولة عن عنوان URL، وتزويدها بمعاملات محوَّلة ومتحقَّق منها مسبقًا، ثم تحويل قيمتها المُرجَعة إلى استجابة HTTP. وهكذا يقتصر عملك على كتابة دوال Java تستقبل كائنات وتُرجع كائنات.
التعليقات
التعليقات مدعومة عبر GitHub Discussions
سجّل الدخول باستخدام GitHub للمشاركة في النقاش