مبادئ التصميم المقصود لجاكرتا EE

مرحبا يا هبر! نشرنا مؤخرًا كتاب " تعلم Java EE. البرمجة الحديثة للمؤسسات الكبيرة " لبطل جافا الألماني سيباستيان داشنر.


يكتب السيد داشنر بنشاط ويتحدث عن الموضوعات المتعلقة بـ Java EE الحديثة ، لذلك لم تتجاهل مدونته مبادئ التصميم العامة لمنصة جاكرتا EE ، التي طورتها الآن Eclipse. ترجمة هذا المقال بالذات (يونيو) نلفت انتباهكم اليوم.

تتولى منصة جاكارتا للكهرباء تدريجيًا ، وتظهر معها مواصفات جديدة لتطوير المشاريع. للاتفاق على مختلف المعايير والتقنيات التي على وشك الظهور ، لن يستفيد مجتمع Java EE بالكامل إلا إذا تم تطوير مبادئ التصميم العامة لمواصفات جاكرتا EE.

أعتقد أن تقنية Java EE كانت ناجحة للغاية مع القليل من المبادئ. أدناه سوف أعرض وجهة نظري حول أي مبادئ التصميم التي تم تطويرها في Java EE تبدو بالنسبة لي الأكثر أهمية ، والتي تستحق المزيد من الدراسة ويمكن أن تكون بمثابة توصيات للتصميم في Jakarta EE.

قررت أن أكتب هذا المقال ، مستوحى من مقترحات دميتري كورنيلوف حول الاتجاه الذي يجب أن يسير فيه التطوير التقني لجاكرتا EE.

أول شيء هو منطق الأعمال

يسمح نموذج البرمجة المعتمد في Java EE للمطور بالتركيز على ما هو مطلوب بالضبط - أي منطق الأعمال. لم تعد بحاجة إلى وراثة فئات API ؛ يمكن للمطور التعبير عن منطق مجال موضوعه بلغة جافا المعتادة والتحكم بشكل إلزامي (باستخدام التعليقات التوضيحية) في التحكم في سلوك خادم التطبيق. وبالتالي ، يندمج الإطار بسلاسة في التعليمات البرمجية الخاصة بك ، وفي جوهره ، من السهل إزالته من هناك. عند التصميم ، لا تعتمد على إعادة الاستخدام ، ولكن على سهولة الإزالة.

ومع ذلك ، يجب أن تخفف عمليات التنفيذ إلى أقصى حد المطور من أصعب العمل - أي السماح له بالهروب من المتطلبات التقنية التي لا تتعلق بمنطق الأعمال. ومن الأمثلة على مؤشرات الترابط أو المعاملات أو عكس التحكم أو معالجة طلب HTTP. على الجانب التطبيق ، مملة جيدة :)

يبدو من المهم بالنسبة لي أن الإطار لا يتداخل فقط مع تنفيذ منطق الأعمال ، ولكنه يشجع أيضًا المبرمجين على تقديم ميزات متطورة للإنتاج بسرعة. ليست هناك حاجة لتلميع الإطار للتألق - من الأفضل جعل كود منطق الأعمال إلى المثالية. قارن Java EE أو Spring الحديث مع الإصدارات القديمة من J2EE - أعتقد أنك ستفهم على الفور ما أعنيه.

يجب على جاكرتا EE أن تتطور في نفس السياق ، وبالتالي التركيز على المواصفات التي ستسمح للمطورين بتنفيذ منطق الأعمال بسرعة.

اصطلاحات التكوين

يعمل Java EE على تقليل التكوين المطلوب لتحديد تطبيق نموذجي للمؤسسات. في معظم المواقف العملية ، تعمل الاتفاقيات فور إخراجها من الصندوق ، ولا يلزم تكوين. لذا ، لم تعد بحاجة إلى أي ملفات XML لتكوين تطبيق Java EE بسيط. مثال آخر هو أن JAX-RS يوفر رموز استجابة HTTP الافتراضية التي تتوافق مع قيم الإرجاع لطرق JAX-RS.

تتمتع Java EE بالمرونة لتعديل السلوك وتنفيذ البرامج النصية الأكثر تعقيدًا ؛ ومع ذلك ، لا يوجد اتفاق على هذا.
يجب على جاكرتا EE الاستمرار في تحويل البسيط إلى السهل ، والمعقد إلى الممكن.

مواصفات قابلية التشغيل البيني

يجب على جاكرتا EE مواصلة وتوسيع قابلية التشغيل البيني للمواصفات. يتوافق Java EE مع المواصفات الموجودة والوظائف الموجودة فيها والتي أصبحت بالفعل جزءًا من المعيار.

يمكن للمطورين الاعتماد على مواصفات متباينة للتفاعل بشكل جيد مع بعضهم البعض ، دون أي تكوين مطلوب. المعايير المطلوبة: إذا كانت بيئة وقت التشغيل تدعم كلاً من المواصفات أ والمواصفات ب ، فيجب أن تتفاعل أ + ب مع بعضها البعض. أمثلة: يمكن التحقق من صحة المكون ، أو JAXB ، أو JSON-B في فئات موارد JAX-RS ، ولا يلزم تكوين إضافي.

حقن التبعية و CDI

بالطبع ، من غير المرغوب فيه أن تقوم شركة Jakarta EE بإعادة اختراع تلك الأشياء الموجودة بالفعل - على سبيل المثال ، حقن التبعية المتعلقة بـ CDI. من المستحسن أن تستخدم المواصفات وتؤكد نقاط القوة في JSR 330 أو ، إذا لزم الأمر ، CDI.

مثال UriInfo هو استخدام UriInfo من JAX-RS في طرق الموارد. لا @Inject التعليقات التوضيحية @Inject بعد تنفيذ هذا النوع من الأساليب. إنه أكثر ملاءمة للمبرمج للعمل ، وكلما اعتمد على الآلية العالمية.

مقياس محدد آخر هو هذا: يجب توفير موفري CDI في المواصفات ، وإذا لزم الأمر ، مؤهلات أنواع آمنة للأنواع التي يجب إنشاؤها. لذلك ، في الوقت الحالي ، لا يمكن الحصول على مثيل عميل JAX-RS برمجيًا إلا من خلال واجهة برمجة تطبيقات ClientBuilder . يبسط المصنعون والمؤهلون عمل المبرمج من خلال تقديم تعريفات تعريفية.

مناهج تعريفية

لكل هذا ، تعتمد واجهة برمجة تطبيقات Java EE API بشكل كبير على نهج تعريفي ، أثناء استخدام عكس التحكم. وبالتالي ، لا يقوم المطورون باستدعاء الوظيفة مباشرة ؛ الحاوية مسؤولة عن استدعاء الوظيفة ، بينما نعتمد على تعريفات التعليمات البرمجية. الأمثلة (من أحدث المواصفات) هي JAX-RS أو JSON-B أو CDI.

لا توفر Jakarta EE فقط واجهات برمجة تطبيقات أكثر شمولاً ، ولكن يجب أن تسهل استخدام التعريفات التعريفية والتحكم في الانقلابات.

استراتيجيات النشر

السمة المميزة (وفي رأيي ميزة كبيرة) لـ Java EE هي أن نموذج النشر المقترح هنا ، والذي تتعارض فيه مشكلات منطق الأعمال عن التنفيذ. برامج المطورين حصريًا لواجهة برمجة التطبيقات ، وهي ليست جزءًا من أداة النشر ويتم تنفيذها بواسطة حاوية التطبيق.
تبسط أدوات النشر المدمجة هذه وتسريع تسليم البرنامج ، بما في ذلك التجميع والنشر والنشر على هذا النحو. كما أنها متوافقة مع مستويات نظام ملفات الحاوية المستخدم ، على سبيل المثال ، في Docker. أثناء عملية التجميع ، ما عليك سوى إعادة إنشاء العناصر المتغيرة أو إعادة تقديمها.

من الناحية المثالية ، يجب أن تحتوي عناصر النشر على منطق الأعمال فقط ولا شيء آخر ؛ يتم تسليم تطبيقات وقت التشغيل والمكتبات الخارجية التي يُحتمل أن تتم إضافتها بمستوى أقل ، على سبيل المثال ، في مكتبات خادم التطبيقات المضافة في المرحلة السابقة من تجميع الحاوية.

في جاكرتا EE ، يجب أيضًا اعتبار القطع الأثرية المنشورة كيانات من الدرجة الأولى. ربما ستكون هناك فرصة لزيادة إحكام بيئة التشغيل بناءً على المواصفات المطلوبة في التطبيق. ومع ذلك ، تتوقع Jakarta EE إيلاء أقصى قدر من الاهتمام لمنطق الأعمال وإنتاجية المطور ، وصقل وقت التنفيذ هو بالفعل ثانوي.

قابلية الاختبار

بتطبيق المبادئ المذكورة أعلاه ، خاصة إعطاء الأفضلية للبرمجة التعريفية وحقن التبعية ، نقوم بتحسين قابلية اختبار رمز الأعمال. وبالتالي ، يمكن للمطورين إنشاء كائنات مباشرة في البرامج النصية للاختبار ، لأنك الآن لا تحتاج إلى وراثة فئات واجهة برمجة التطبيقات أو استدعاء وظائف غير ملائمة قد تحتاج إلى محاكاة لها في السابق.

ومع ذلك ، في Jakarta EE ، من الضروري التحسين الجاد لتوحيد اختبار التكامل على مستوى الرمز ، بحيث لا يعتمد على الشركة المصنعة. سابقًا ، هذا بالضبط ما كان عليك التعامل معه عند العمل مع Arquillian. في المشاريع الحقيقية ، سيكون مثل هذا المعيار مفيدًا ، والذي يسمح لك بتعريف سيناريوهات النشر التجريبية ووظيفة الاتصال فقط لمكون واحد أو أكثر. في وقت سابق ، كتبت أنني لا أعتبر اختبار التكامل على مستوى الرمز مهمًا للغاية ، على سبيل المثال ، عند تشغيل تطبيق في حاويات مدمجة. ومع ذلك ، إذا قمت بتوحيد اختبارات التكامل على مستوى الكود ، فسيكون لذلك تأثير إيجابي.

الخلاصة

أعتقد أنه ليس من قبيل المصادفة أن يتم استخدام واجهات برمجة تطبيقات Java EE API على نطاق واسع في المشاريع الحقيقية: تم تصميم واجهات برمجة التطبيقات هذه جيدًا وتصميمها وفقًا لمبادئ واضحة ، والتي بفضلها كان من الممكن توحيد ليس فقط مواصفات واحدة ، ولكن منصة كاملة. تسمح لك باستخدام العديد من المواصفات في وقت واحد ، والحفاظ عليها بنفس الروح. هنا ، تمكنا من التخلص من العقبات الاصطناعية التي تعقد عمل المبرمج فقط - لذلك ، أعتقد أن كل تطوير المشاريع أصبح أكثر متعة.