الوصول إلى البيانات

حتى الآن، كانت بيانات التطبيق تعيش في قوائم داخل الذاكرة. كان ذلك كافيًا لفهم التوجيه (routing) وربط النماذج بالكائنات، لكنه لا يصمد بعد ذلك: يختفي كل شيء عند إعادة التشغيل، ولا يُشارَك شيء بين نسختين من التطبيق، ولا يمكن التعبير عن أي استعلام دقيق نسبيًا.

الانتقال إلى قاعدة بيانات علائقية هو اللحظة التي تتدهور فيها تصاميم كثير من تطبيقات Spring MVC. فالمتحكم، الذي كان بسيطًا إلى هذه اللحظة، يبدأ بفتح الاتصالات وكتابة SQL وإدارة المعاملات. وتظهر فيه كتل try/catch/finally حول موارد JDBC، وشيفرة لتحويل ResultSet إلى كائنات، وإدارة للأخطاء تختلف من دالة إلى أخرى. وهكذا يعود المتحكم إلى ما كان Spring MVC يهدف إلى إزالته بالضبط: مكان يختلط فيه كل شيء.

والمشكلة ليست جمالية فحسب. فخلط الوصول إلى البيانات بطبقة الويب يجعل المعاملات خارج السيطرة. دالة متحكم تكتب في ثلاثة جداول دون حدّ معاملاتي صريح قد تترك قاعدة البيانات في حالة وسطية إذا فشلت الكتابة الثالثة، ولا شيء في الشيفرة يشير إلى وجود هذا الخطر.

يرسّخ هذا الدرس التقسيم الذي يتجنب ذلك: كيان (Entity) يصف الجدول، ومستودع (Repository) يوفر الاستعلامات، وخدمة (Service) تحمل المنطق التجاري وتحدد حدود المعاملات، ومتحكم (Controller) لا يفعل سوى ترجمة HTTP. ونضيف الترقيم (pagination) لأن القائمة غير المرقّمة عطل مؤجَّل، ونعالج فخ التحميل الكسول (lazy loading) الذي يُنتج استثناءات LazyInitializationException في منتصف الصفحة.