21. الخلاصة
دعونا نستعرض ما تم عرضه في هذا المستند:
- أساسيات برمجة الويب بلغة Java باستخدام السيرفلتات وصفحات JSP
- مقدمة إلى بنية MVC
- مقدمة إلى بنية 3-tier
- مقدمة إلى Spring IoC
- أمثلة لتوضيح هذه النقاط
نعتقد أن القراء الذين وصلوا إلى هذه المرحلة أصبحوا جاهزين لتطوير تطبيقات الويب الخاصة بهم بلغة Java. كما أنهم جاهزون للتعامل مع أساليب تطوير أخرى مشابهة لتلك التي تم تناولها في هذا المستند. دعونا نستعرض بنية تطبيقات الويب التي تم تطويرها هنا:
 |
بالنسبة للتطبيقات البسيطة، هذه البنية كافية. بمجرد كتابة عدة تطبيقات من هذا النوع، ستلاحظ أن سيرفلتات تطبيقين مختلفين:
- تستخدمان نفس الآلية لتحديد الطريقة [doAction] التي يجب تنفيذها لمعالجة الإجراء المطلوب من قبل المستخدم
- في الواقع لا يختلفان إلا في محتوى طرق [doAction] هذه
ومن ثم، يكون الإغراء قويًا للقيام بما يلي:
- تقسيم المعالجة (1) إلى سيرفلت عام لا يعرف التطبيق الذي يستخدمه
- تفويض المعالجة (2) إلى فئات خارجية نظرًا لأن السيرفلت العام لا يعرف في أي تطبيق يتم استخدامه
- ربط الإجراء المطلوب من قبل المستخدم بالفئة التي يجب أن تعالجه باستخدام ملف تكوين
وقد ظهرت أدوات، تُعرف غالبًا باسم «الأطر»، لتزويد المطورين بهذه الإمكانيات. وأقدمها وأشهرها على الأرجح هو Struts (http://struts.apache.org/). ويُعد Jakarta Struts أحد مشاريع مؤسسة Apache للبرمجيات (www.apache.org). ويرد وصف لهذا الإطار في (http://tahe.developpez.com/java/struts/).
يقدم إطار عمل Spring (http://www.springframework.org/)، الذي ظهر مؤخرًا، ميزات مشابهة لتلك الموجودة في Struts. ويشير هذا على وجه التحديد إلى وحدة Spring MVC الخاصة به. وقد تم وصف استخدامه في عدة مقالات (http://tahe.developpez.com/java/springmvc-part1/).
لا يقتصر Spring على مفهوم MVC لطبقة [الويب] في تطبيق ثلاثي الطبقات. فهو مفيد حتى في التطبيقات خارج نطاق الويب.
وبالتالي، اختتمنا دورتنا بتنفيذ بنية MVC ضمن بنية ثلاثية الطبقات [الويب، منطق الأعمال، DAO] باستخدام مثال أساسي لإدارة قائمة بالأشخاص.
 |
في الإصدار 1 من التطبيق، كانت قائمة الأشخاص محفوظة في الذاكرة وتختفي عند إغلاق التطبيق الويب. أما في الإصدارات الأخرى، فتُخزّن قائمة الأشخاص في جدول قاعدة بيانات. وقد استخدمنا أربعة أنظمة إدارة قواعد بيانات مختلفة: Firebird وPostgres وMySQL وSQL Server Express.
بفضل Spring IoC، أمكن الاحتفاظ بالطبقة [الويب] من الإصدار 1 بالكامل في الإصدارات اللاحقة. وبذلك أثبتنا أنه من الممكن بناء بنى ذات مستويات متعددة (n-tier) ذات طبقات مستقلة.
مع الإصدارات التي تستخدم قاعدة بيانات، أثبتنا مساهمة Spring في بناء طبقات [DAO] و[service]. بفضل تكامل Spring مع iBATIS، تمكنا من بناء أربعة إصدارات تختلف فقط في ملفات التكوين الخاصة بها. تم استخدام نفس فئة [DaoImplCommon] لتنفيذ طبقة [dao] في جميع الإصدارات الأربعة. لمعالجة مشكلة خاصة بنظام إدارة قواعد البيانات Firebird، كان علينا اشتقاق هذه الفئة ولكن لم نحتاج إلى تعديلها.
وأخيرًا، أوضحنا كيف سمح لنا Spring بإدارة المعاملات بشكل إعلاني في طبقة [service].
نشجع القراء على استكشاف جميع الميزات التي يقدمها هذا المنتج.