4. تطوير MVC (النموذج – العرض – وحدة التحكم)
غالبًا ما يكون لتطبيق الويب بنية ثلاثية الطبقات:
- تتولى الطبقة [dao] الوصول إلى البيانات، وغالبًا ما تكون بيانات ثابتة داخل SGBD. ولكن قد تكون أيضًا بيانات مستمدة من أجهزة استشعار أو من الشبكة، ...
- تقوم الطبقة [metier] بتنفيذ الخوارزميات "المهنية" للتطبيق. هذه الطبقة مستقلة عن أي شكل من أشكال واجهة المستخدم. وبالتالي، يجب أن تكون قابلة للاستخدام مع واجهة وحدة التحكم، وواجهة الويب، وواجهة العميل الغنية. وبالتالي، يجب أن يكون من الممكن اختبارها خارج واجهة الويب، ولا سيما مع واجهة وحدة التحكم. وهي عادةً الطبقة الأكثر استقرارًا في البنية. ولا تتغير إذا تم تغيير واجهة المستخدم أو طريقة الوصول إلى البيانات اللازمة لتشغيل التطبيق.
- الطبقة [interface utilisateur] وهي الواجهة (غالبًا رسومية) التي تسمح للمستخدم بتشغيل التطبيق وتلقي المعلومات منه.
تتم الاتصالات من اليسار إلى اليمين:
- يقوم المستخدم بتقديم طلب إلى الطبقة [interface utilisateur]
- يتم تنسيق هذا الطلب بواسطة الطبقة [interface utilisateur] ونقله إلى الطبقة [métier]
- إذا احتاجت الطبقة [métier] إلى بيانات لمعالجة هذا الطلب، فإنها تطلبها من الطبقة [dao]
- تقوم كل طبقة يتم الاستعلام عنها بإرسال ردها إلى الطبقة الموجودة على يسارها حتى الوصول إلى الرد النهائي للمستخدم.
عادةً ما تُستخدم الطبقتان [métier] و [dao] عبر واجهات Java. وبالتالي، فإن الطبقة [métier] لا تعرف عن الطبقة [dao] سوى واجهتها أو واجهاتها، ولا تعرف الفئات التي تنفذها. وهذا ما يضمن استقلالية الطبقات عن بعضها البعض: لا يؤثر تغيير تنفيذ الطبقة [dao] على الطبقة [métier] ما لم يتم تغيير تعريف واجهة الطبقة [dao]. وينطبق الأمر نفسه على الطبقتين [interface utilisateur] و [métier].
تقع بنية MVC (النموذج – العرض – وحدة التحكم) في الطبقة [interface utilisateur] عندما تكون هذه الأخيرة واجهة ويب:
تتم معالجة طلب العميل وفقًا للخطوات التالية:
- يقدم العميل طلبًا إلى وحدة التحكم. تمر جميع طلبات العملاء عبر وحدة التحكم. وهي بوابة الدخول إلى التطبيق. وهي تمثل الحرف C في MVC.
- يقوم وحدة التحكم C بمعالجة هذا الطلب. وللقيام بذلك، قد يحتاج إلى مساعدة من طبقة الأعمال. بمجرد معالجة طلب العميل، يمكن أن يستدعي هذا الطلب استجابات متنوعة. ومن الأمثلة النموذجية على ذلك:
- صفحة أخطاء إذا تعذر معالجة الطلب بشكل صحيح
- صفحة تأكيد في الحالات الأخرى
- يختار وحدة التحكم الاستجابة (= العرض) التي سيتم إرسالها إلى العميل. يتطلب اختيار الاستجابة التي سيتم إرسالها إلى العميل عدة خطوات:
- اختيار الكائن الذي سيقوم بتوليد الاستجابة. وهذا ما يُسمى العرض V، حرف V في MVC. يعتمد هذا الاختيار عمومًا على نتيجة تنفيذ الإجراء الذي طلبه المستخدم.
- تزويده بالبيانات التي يحتاجها لتوليد هذا الرد. في الواقع، غالبًا ما يحتوي هذا الرد على معلومات يحسبها المتحكم. تشكل هذه المعلومات ما يُسمى نموذج M للعرض، وهو حرف M في MVC.
- تتمثل الخطوة 3 إذن في اختيار عرض V وبناء النموذج M اللازم له.
- يطلب عنصر التحكم C عرض «الطريقة» المحددة. وغالبًا ما يتم ذلك عن طريق تنفيذ طريقة معينة في «الطريقة» V المسؤولة عن إنشاء الاستجابة للعميل. في هذا المستند، سنطلق مصطلح «الطريقة» على كل من الكائن الذي ينشئ الاستجابة للعميل وعلى الاستجابة نفسها. لا توضح الوثيقة MVC هذه النقطة بشكل صريح. إذا كان من المفترض أن يُطلق على الرد اسم "عرض"، فيمكننا أن نطلق على الكائن الذي يولد هذا الرد اسم "مولد العرض".
- يستخدم مولد العرض V النموذج M الذي أعده وحدة التحكم C لتهيئة الأجزاء الديناميكية من الرد الذي يجب أن يرسله إلى العميل.
- يتم إرسال الاستجابة إلى العميل. يعتمد الشكل الدقيق لهذه الاستجابة على مولد العرض. يمكن أن يكون تدفقًا HTML، أو PDF، أو Excel، ...
لا تتطلب منهجية تطوير الويب MVC بالضرورة أدوات خارجية. وبالتالي، يمكن تطوير تطبيق ويب Java بهيكل MVC باستخدام JDK بسيط ومكتبات أساسية لتطوير الويب. فيما يلي طريقة يمكن استخدامها للتطبيقات البسيطة:
- يتم التحكم بواسطة سيرفلت واحد. وهو C في MVC.
- تحتوي جميع طلبات العميل على سمة action، على سبيل المثال (http://.../appli?action=liste).
- وفقًا لقيمة السمة action، تقوم الخدمة بتنفيذ طريقة داخلية من النوع [doAction(...)].
- تقوم الطريقة [doAction] بتنفيذ الإجراء المطلوب من قبل المستخدم. ولهذا الغرض، تستخدم الطبقة [métier] إذا لزم الأمر.
- وفقًا لنتيجة التنفيذ، تقرر الطريقة [doAction] الصفحة JSP التي سيتم عرضها. هذه هي طريقة العرض V للنموذج MVC.
- تحتوي الصفحة JSP على عناصر ديناميكية يجب أن توفرها الخدمة. ستوفر الطريقة [doAction] هذه العناصر. هذا هو نموذج العرض، M من MVC. يتم وضع هذا النموذج في الغالب في سياق الطلب (request.setAttribute("مفتاح"، "قيمة")، أو في حالات أقل تواتراً، في سياق الجلسة أو التطبيق. تتمتع الصفحة JSP بإمكانية الوصول إلى هذه السياقات الثلاثة.
- تقوم الطريقة [doAction] بعرض العرض عن طريق نقل تدفق التنفيذ إلى الصفحة JSP المختارة. وهي تستخدم لهذا الغرض تعليماً من نوع [getServletContext() .getRequestDispatcher(" pageJSP ").forward(request, response)].
يُطلق على نمط الهندسة (Design Pattern) MVC اسم نمط "Front Controller" أو نمط وحدة التحكم الفردية. تعالج وحدة خدمة واحدة جميع الطلبات من جميع المستخدمين.
لنعد إلى بنية تطبيق الويب السابق:
تتوافق هذه البنية مع بنية ntier التالية:
في الواقع، لا توجد سوى طبقة واحدة، وهي طبقة واجهة الويب. بشكل عام، سيكون لتطبيق الويب MVC القائم على السيرفلتات والصفحات JSP البنية التالية:
بالنسبة للتطبيقات البسيطة، هذه البنية كافية. وعندما نكتب عدة تطبيقات من هذا النوع، نلاحظ أن السيرفلتات في تطبيقين مختلفين:
- لديهما نفس الآلية لتحديد الطريقة [doAction] التي يجب تنفيذها لمعالجة الإجراء المطلوب من قبل المستخدم
- لا تختلف في الواقع إلا في محتوى هذه الطرق [doAction]
ومن ثم، فإن الإغراء كبير لـ:
- تحليل المعالجة (1) في سيرفلت عام لا يعرف التطبيق الذي يستخدمه
- تفويض المعالجة (2) إلى فئات خارجية نظرًا لأن السيرفلت العام لا يعرف في أي تطبيق يتم استخدامه
- ربط الإجراء المطلوب من قبل المستخدم بالفئة التي يجب أن تعالجه باستخدام ملف تكوين
ظهرت أدوات، تُسمى غالبًا "أطر عمل"، لتوفر المزايا السابقة للمطورين. أقدمها وربما أشهرها هو Struts (http://struts.apache.org/). Jakarta Struts هو مشروع تابع لمؤسسة Apache Software Foundation (www.apache.org). تم وصف هذا الإطار في (http://tahe.developpez.com/java/struts/).
أما إطار العمل Spring (http://www.springframework.org/) الذي ظهر مؤخرًا، فيقدم ميزات مشابهة لتلك التي يقدمها Struts. وقد تم وصف استخدامه في عدة مقالات (http://tahe.developpez.com/java/springmvc-part1/).
نقدم الآن مثالاً على بنية MVC القائمة على السيرفلت والصفحات JSP.