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

"لذا ، سأخذ نظام إدارة قواعد البيانات الذي أعرفه والذي يناسب أحجام بياناتهم ، وأربط Hibernate / JPA ، وكتابة التطبيق على Spring Boot ، وكشف واجهة برمجة تطبيقات REST وكتابة العميل في إطار JS ، على الأرجح Angular / React."

"نعم ، ما زلنا بحاجة إلى حل الربيع الأمن. وكتابة قيود على الوصول إلى البيانات للأقسام والأدوار المختلفة - على مستوى صفوف قاعدة البيانات أو كائنات البيانات. كيف تفعل ذلك؟ إرسال أو VPD ، ستحتاج إلى المشاهدة ".

"آه ، يجب أن أكتب مجموعة من DAOs - تتم بسرعة ، ولكن هناك الكثير."

"والتحويل من الكيان إلى DTO - أنا أستخدم ModelMapper ."

"الشيء الرئيسي هو عدم نسيان تذكير المتدرب بالصفات الكسولة والانضمام حتى لا يكون هناك ، مثل آخر مرة."

"أشجار التنوب ، بينما تبدأ منطق الأعمال ، تحتاج إلى كتابة الكثير من كود الخدمة ..."

هذه المقالة مخصصة لأولئك الذين كتبوا على الأقل تطبيقين من المؤسسات من الصفر على Boot Spring / Spring ، ويعتقدون الآن أنه سيكون من اللطيف تسريع تطوير هذه التطبيقات المختلفة ، ولكن في نفس الوقت ، بطريقة أو بأخرى. بعد ذلك ، سنرى كيفية التخلص من المهام "النموذجية" باستخدام منصة CUBA .

إطار آخر؟

الفكر الأول ، عندما يُعرض على المطور إطار عمل جديد (وعلى وجه الخصوص ، CUBA) ، فهو: "لماذا يجب أن أزعجك بهذا؟ سوف آخذ الحذاء الربيعي المألوف والمألوف وسأنهي كل شيء ". وهذا أمر معقول. الإطار الجديد هو دراسة مناهج التنمية الجديدة والمزالق والقيود الجديدة التي تعلمتها لتجنبها بذكاء عند تطويرها في إطار مألوف.

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

دعونا نبدأ من البداية ونرى كيف يقارن تطوير CUBA بالطريقة المعتادة للتطور في Spring وكيف ، باستخدام تجربتك وتعلم بعض الأشياء الجديدة ، يمكنك في نهاية المطاف إنشاء تطبيقات بشكل أسرع.

ينصب التركيز الرئيسي للمقال على تطوير جانب الخادم حتى لا يفقد التركيز ويحافظ على كمية النص عند مستوى مقبول.

الربيع تطبيق العمارة

في 90٪ من الحالات ، عند كتابة "هندسة تطبيقات الربيع" أو "هندسة تطبيقات الربيع" في Google ، سترى صورة مماثلة. تطبيق كلاسيكي من ثلاث طبقات مع وحدات مشتركة لبعض الطبقات.



نموذج المجال (نموذج المجال) - فئات الكيانات للمجال (الكيانات) ، المخزنة ، كقاعدة ، في قاعدة البيانات. عادةً ما يتم إنشاء الفصول يدويًا ، ولكن يمكنك إنشاء البنية تلقائيًا ، بناءً على مخطط قاعدة البيانات.

طبقة مستودع (طبقة مستودع) - مجموعة من الفئات التي توفر العمل مع مستودع البيانات. عادةً ما تستخدم هذه الطبقة أطر ORM المتنوعة وتحتوي على منطق لتنفيذ عمليات CRUD. إذا كنا نتحدث عن Spring ، فإن المستودعات صغيرة جدًا ، ويرجع ذلك أساسًا إلى طرق الاستعلام JPA ، ولكن غالبًا ما يتعين عليك كتابة منطق التحديد من قاعدة البيانات وتعيينه يدويًا إلى نموذج المجال.

طبقة الخدمة - طبقة تطبيق تحتوي على تنفيذ منطق الأعمال وخوارزميات معالجة المعلومات الخاصة بمنطقة الموضوع. هذا مفيد في حالة خوارزميات المعالجة المعقدة ، وكذلك للعمل مع البيانات من مصادر مختلفة (قواعد البيانات والتطبيقات الخارجية والخدمات من الإنترنت ، وما إلى ذلك).

طبقة الويب / وحدات التحكم - الطبقات المسؤولة عن REST API. قد تكون هناك أيضًا ملفات قالب صفحة على هذه الطبقة إذا استخدمنا إطارًا مثل Thymeleaf و Velocity ، بالإضافة إلى الفئات المسؤولة عن عرض ومعالجة أحداث واجهة المستخدم إذا تم استخدام شيء مثل GWT و Vaadin و Wicket وما إلى ذلك. بشكل عام ، تعمل وحدات التحكم مع DTO ، وليس مع الفئات من طبقة المجال ، لذلك يتم إضافة وظيفة تحويل DTO إلى Entity والعكس بالعكس إلى التطبيق.
إذا كان كل ما سبق واضحًا لك ، أو حتى "الكابتن العادي" ممتاز. لذلك يمكنك البدء في العمل مع CUBA دون أي مشاكل.

التطبيق المرجعي - عيادة الحيوانات الأليفة

دعونا نلقي نظرة على مثال محدد ونكتب بعض التعليمات البرمجية. بالنسبة للربيع ، يوجد تطبيق "مرجعي" - Pet Clinic على GitHub . تم إنشاء هذا التطبيق في إصدارات مختلفة باستخدام أدوات مختلفة - من الربيع الكلاسيكي إلى Kotlin و Angular. بعد ذلك سنرى كيفية جعل هذا التطبيق على CUBA. بالنسبة لأولئك الذين ليسوا على دراية بإصدار الربيع ، هناك نص جيد هنا ؛ سيتم استخدام مقتطفات منه في هذه المقالة.

نموذج البيانات

يظهر الرسم البياني ER في الشكل أعلاه. يكرر نموذج المجال هذا الهيكل ، وتضاف إليه العديد من الفئات ذات الحقول المشتركة ، وقد تم بالفعل توريث فئات الكيانات منها. يمكن العثور على UML في العرض التقديمي الذي ذكرته سابقًا.

طبقة المستودع

هناك أربعة مستودعات في التطبيق مسؤولة عن العمل مع مالك الكيانات (المالك) ، والحيوانات الأليفة (الحيوانات الأليفة) ، والزيارة (الزيارة) ، والبيطري (الطبيب البيطري). تتم كتابة المستودعات باستخدام Spring JPA ولا تحتوي على أي كود تقريبًا ، فقط إعلانات الطرق. ومع ذلك ، تمت إضافة استعلام إلى المستودع الذي يعمل مع كيان المالك ، والذي يسمح باستخراج المالكين وحيواناتهم الأليفة من قاعدة البيانات في عينة واحدة.

واجهة المستخدم

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

اختياري

بالإضافة إلى التعليمات البرمجية للتلاعب البسيط مع الكيانات ، يحتوي التطبيق على وظائف مثيرة للاهتمام تم تصميمها لإظهار قدرات Spring:

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

ملاحظات هامشية

انا حقا احب هذه الصورة تعكس 100 ٪ مشاعري عند العمل مع الأطر. لاستخدام الإطار بشكل فعال ، يجب أن تفهم كيف يتم بناؤه في الداخل (بغض النظر عن أي شيء). على سبيل المثال ، كم منكم تساءل عن عدد الفصول اللازمة لتشغيل واجهة JPA؟
حتى في تطبيق صغير مثل Pet Clinic ، هناك القليل من سحر Boot Spring:

• لا يوجد تكوين لذاكرة التخزين المؤقت (باستثناء التعليق التوضيحي @Caheable ) ، ومع ذلك ، فإن Spring Boot "يعرف" كيفية بدء ذاكرة التخزين المؤقت المطلوبة (EhCache في هذه الحالة).
• لم يتم وضع علامة على مستودعات CRUD بعلامة @Transactional ( @Transactional الأصل هي org.springframework.data.repository.Repository أيضًا) ، ولكن جميع طرق save() تعمل كما هو متوقع.

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

عيادة الحيوانات الأليفة على منصة CUBA

حسنًا ، دعنا نلقي نظرة على عيادة الحيوانات الأليفة ، التي تم إجراؤها باستخدام CUBA ، من وجهة نظر مطور الربيع ونحاول أن نفهم أين يمكنك حفظه.

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

بنية تطبيق CUBA

يتكون تطبيق CUBA من الوحدات الموضحة في الرسم التخطيطي.



عالمي (وحدة عامة) - يحتوي على فئات الكيانات ، وتمثيلات CUBA وواجهات الخدمة التي يتم استخدامها في وحدات مختلفة.

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

واجهة المستخدم الرسومية ، الويب ، سطح المكتب ، البوابة - تحتوي هذه الوحدات على رمز للفئات المتعلقة بمعالجة حدث واجهة المستخدم ، بالإضافة إلى وحدات تحكم REST إضافية إذا لم تكن واجهة برمجة تطبيقات CUBA REST المدمجة كافية.

لتوفير وقت المطور ، لدى CUBA استوديو - بيئة تطوير رسومية صغيرة تساعد على القيام بأعمال روتينية ، مثل إنشاء الكيانات ، وتسجيل الخدمات في ملفات التكوين ، إلخ. باستخدام الواجهة الرسومية. لإنشاء واجهة التطبيق المطور ، هناك محرر WYSIWYG (تقريبًا).

وبالتالي ، فإن التطبيق القائم على منصة CUBA يتكون من وحدتين رئيسيتين - Core و GUI ، والتي يمكن نشرها بشكل منفصل ، بالإضافة إلى وحدة مشتركة - Global. دعونا نلقي نظرة فاحصة على تصميم هذه الوحدات.

الوحدة العالمية

نموذج الكيان

لا يختلف تصميم الكيانات في تطبيق CUBA عما اعتاد عليه مطورو Spring. يتم إنشاء فئات المجال ووضع التعليقات التوضيحية @Table @Entity و @Entity وما إلى ذلك. ثم يتم تسجيل هذه الفئات في ملف persistence.xml .

عند كتابة Pet Clinic ، قمت للتو بنسخ الفصول من تطبيق Spring الأصلي وقمت بتغييرها قليلاً. فيما يلي بعض الإضافات الصغيرة التي تحتاج إلى معرفتها إذا كتبت على منصة CUBA:

1. يقدم CUBA مفهوم " مساحة الاسم " لكل مكون من مكونات التطبيق لتجنب ازدواجية أسماء الجداول في قاعدة البيانات. لهذا السبب تمت إضافة البادئة "petclinic $" إلى كل كيان.
2. يوصى باستخدام التعليق التوضيحي @NamePattern - وهو تناظري لطريقة toString() لعرض قابل للقراءة للكيانات في واجهة المستخدم.

سؤال طبيعي: "ماذا يضيف CUBA أيضًا إلى جانب البادئات والإعلانية إلى toString() ؟" فيما يلي قائمة جزئية بالميزات الإضافية:

1. فئات أساسية ذات معرفات تم إنشاؤها تلقائيًا من عدد صحيح إلى معرفات UUID.
2. واجهات علامة مفيدة توفر ميزات إضافية:
   
   • Versioned - لدعم إصدار مثيلات الكيان.
   • SoftDelete - لدعم الحذف "المنطقي" للسجلات في قاعدة البيانات.
   • Updatable - تتم إضافة الحقول لتسجيل حقيقة تحديث السجل واسم المستخدم والوقت.
   • Creatable - تتم إضافة الحقول لتسجيل إنشاء سجل.
   
   يمكنك قراءة المزيد عن نمذجة الكيان في الوثائق .
3. يتم إنشاء البرامج النصية لإنشاء وتحديث قاعدة البيانات تلقائيًا باستخدام CUBA Studio.

وهكذا ، فإن إنشاء نموذج بيانات لـ Pet Clinic جاء لنسخ فئات الكيانات وإضافة أشياء خاصة بـ CUBA إليها ، والتي ذكرتها أعلاه.

المشاهدات

قد يبدو مفهوم "التمثيلات" في CUBA غير معتاد إلى حد ما ، ولكن من السهل شرحه. طريقة العرض عبارة عن طريقة تعريفية للإعلان عن السمات التي يلزم استرداد قيمها من مستودع البيانات.

على سبيل المثال ، تحتاج إلى استخراج المالكين وحيواناتهم الأليفة من قاعدة البيانات (أو الأطباء البيطريين ومهنتهم) - مهمة شائعة جدًا عند إنشاء واجهة هي عندما تحتاج إلى إظهار البيانات التابعة في نفس النموذج مثل الرئيسي. في الربيع ، يمكن القيام بذلك من خلال ربط JPA ...

 @Query("SELECT owner FROM Owner owner left join fetch owner.pets WHERE owner.id =:id") public Owner findById(@Param("id") int id); 

... أو تعيين سمات EAGER / LAZY لاسترداد مجموعة الكيان الرئيسي في سياق معاملة واحدة.

 @ManyToMany(fetch = FetchType.EAGER) @JoinTable(name = "vet_specialties", joinColumns = @JoinColumn(name = "vet_id"), inverseJoinColumns = @JoinColumn(name = "specialty_id")) private Set<Specialty> specialties; 

في CUBA ، يمكنك القيام بذلك من خلال EntityManager و JPQL (يعرف الجميع كيف) أو من خلال العرض و DataManager:

1. شكل عرض تقديمي (يمكن القيام به في CUBA Studio أو يدويًا في التكوين)
   
   

    <view class="com.haulmont.petclinic.entity.Vet" extends="_minimal" name="vet-specialities-view"> <property name="specialities" view="_minimal"> </property> </view> 

2. واستخدم DataManager لجلب:

    public Collection<Vet> findAll() { return dataManager.load(Vet.class) .query("select v from cubapetclinic$Vet v") .view("vet-specialities-view") .list(); } 

يمكنك إنشاء طرق عرض مختلفة لمهام مختلفة باستخدام مجموعة السمات ومستويات تداخل الكيانات المطلوبة. هناك مقالة ممتازة عن منشورات مدونة ماريو ديفيد.

تم تقديم ستة طلبات مختلفة لتطبيق Pet Clinic. تم إنشاء معظمها "شبه تلقائي" عند إنشاء واجهة المستخدم ، وتم تنفيذ العرض الموضح أعلاه لخدمة تصدير البيانات.

واجهات الخدمة

نظرًا لأن الوحدة النمطية العامة تستخدم من قبل جميع وحدات التطبيق الأخرى ، يتم الإعلان عن واجهات الخدمة فيها ، بحيث يمكن استخدامها لاحقًا في وحدات أخرى من خلال آلية حقن التبعية (DI).

بالإضافة إلى ذلك ، تحتاج إلى تسجيل الخدمات في web-spring.xml في وحدة الويب. عند تهيئة السياق ، سيعمل CUBA على إنشاء فئات وكيل لتسلسل الفئات وإلغاء تسلسلها عند التفاعل مع الخدمات في الوحدة النمطية الأساسية. هذا يوفر فقط نشرًا منفصلًا لوحدات Core و Web ، بينما لا يحتاج المطور إلى بذل جهود إضافية ، يتم كل شيء بشفافية.

لذلك: عند إنشاء فئات الكيانات في CUBA ، يتم إنفاق نفس مقدار الوقت كما هو الحال في Spring النقي (إذا كنت لا تستخدم CUBA Studio) ، ولكنك لست بحاجة إلى إنشاء فئات أساسية لتوليد المفاتيح الأساسية. كما أنك لا تحتاج إلى كتابة تعليمات برمجية لدعم حقل إصدار الكيان والحذف المنطقي والتدقيق. أيضًا ، في رأيي ، يمكن للآراء توفير بعض الوقت في تصحيح أخطاء الانضمام إلى JPA ومعالجة عينات EAGER / LAZY.

الوحدة الأساسية

تحتوي هذه الوحدة على تطبيقات الواجهات المعلن عنها في الوحدة العامة. يتم @Service كل خدمة في تطبيق CUBA بواسطة @Service ، ويمكنك استخدام التعليقات التوضيحية الربيعية الأخرى ، ولكن عليك مراعاة ما يلي:

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

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

مدير الكيان و DataManager

تستخدم منصة CUBA منصة EntityManager الخاصة بها ، والتي تفوض جزءًا من المكالمات إلى javax.persistence.EntityManager المألوفة ، ولكنها لا تنفذ هذه الواجهة. يوفر EntityManager بشكل أساسي عمليات على مستوى منخفض ولا يدعم بشكل كامل نموذج أمان CUBA. الفئة الرئيسية للعمل مع البيانات هي DataManager ، والتي توفر الوظائف التالية:

• التحكم في الوصول على مستوى الصف والسمة.
• استخدام طرق العرض عند جلب البيانات.
• السمات الديناميكية.

المزيد عن DataManager و EntityManager مكتوب في الوثائق . ليست هناك حاجة للعمل بشكل صريح مع هذه الفئات لتحديد البيانات في مكونات واجهة المستخدم (الجداول ، وما إلى ذلك) ، يتم استخدام مصادر البيانات (مصادر البيانات) في واجهة المستخدم الرسومية.

إذا تحدثنا عن PetClinic - لا يوجد تقريبًا أي كود في الوحدة النمطية الأساسية ، فلا يوجد منطق عمل معقد في هذا التطبيق.

وظائف إضافية من Pet Clinic إلى CUBA

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

التخزين المؤقت

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

فحص الإدخال

يستخدم CUBA BeanValidation للتحقق من صحة البيانات المدخلة. إذا لم توفر الفئات المضمنة الوظائف اللازمة ، يمكنك كتابة منطق الشيكات الخاصة بك . بالإضافة إلى ذلك ، يوفر CUBA فئات Validator ، الموضحة هنا .

تنسيق الإخراج

توفر منصة CUBA العديد من المنسق لمكونات واجهة المستخدم ، يمكنك أيضًا صنعها بنفسك بالإضافة إلى المعيار. يمكنك استخدام التعليق التوضيحي @NamePattern لتمثيل مثيلات الكيان كسلسلة

i18n

يدعم CUBA الإخراج متعدد اللغات باستخدام ملفات message.properties ، ولا جديد هنا. يجعل CUBA Studio إنشاء وتحرير مثل هذه الملفات سريعة وسهلة.

إدارة المعاملات

يتم دعم الأنواع التالية من إدارة المعاملات:

• على دراية بتعليقات الربيع @Transactional ،
• واجهة Persistence (وفئة) إذا كنت بحاجة إلى إدارة معاملات منخفضة المستوى.

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

عيادة الحيوانات الأليفة في بضع ساعات. حقا

لقد صنعت نسخة من Pet Clinic باستخدام واجهة CUBA القياسية في ست ساعات. لا يعني أنني خبير في CUBA (مرت أسبوعين منذ أن بدأت العمل في Haulmont) ، لكن لدي خبرة مع Spring وساعدني كثيرًا.

دعونا نلقي نظرة على تطبيق CUBA من حيث العمارة الكلاسيكية:

نموذج البيانات - فئات الكيانات في الوحدة النمطية العالمية. إنشاء نموذج هو إجراء معروف ومألوف. بفضل فئة BaseIntegerIdEntity لتوفير الوقت الذي تستغرقه عادة للعب مع إنشاء المعرفات.

ليست هناك حاجة لطبقة المستودع . لقد أنشأت العديد من المشاهدات ، وهذا كل شيء. بالطبع ، وفر لي CUBA Studio القليل من الوقت ، لم أكن مضطرًا إلى كتابة ملفات XML يدويًا.

طبقة الخدمة - التطبيق يحتوي على خدمتين فقط لتصدير البيانات إلى JSON و XML. في الإصدار الحالي من تطبيق Spring Boot ، تمت إزالة هذه الميزة ، بالمناسبة. على الرغم من أنها لم تنجح مع JSON. في إصدار CUBA ، أعلنت عن واجهات في الوحدة النمطية العالمية ووضع التنفيذ في Core. لا شيء جديد باستثناء DataManager ، لكن الأمر لم يستغرق وقتًا طويلاً لإتقانها.

طبقة وحدة التحكم - لدى CUBA Pet Clinic وحدة تحكم REST واحدة فقط للتصدير إلى JSON و XML. لقد وضعت وحدة التحكم هذه في وحدة الويب. مرة أخرى ، لا يوجد شيء خاص ، التعليقات التوضيحية هي نفسها ، وحدة تحكم عادية في الربيع.

واجهة المستخدم - إنشاء نماذج CRUD القياسية ، وحتى مع CUBA Studio ، لم تسبب أي صعوبات. لا حاجة لكتابة كود لنقل البيانات إلى المكونات ، لا تحليل للبيانات من نموذج تصفية البيانات ، لا ضجة مع ترقيم الصفحات. هناك مكونات لكل هذا. استغرق الأمر بعض الوقت لجعل الواجهة تبدو مثل تلك المصنوعة في إصدار Spring Boot. لا يزال Vaadin ليس HTML خالصًا ، وكان من الصعب تصميمه.

جدولة التجربة الشخصية:

	سهل الفهم ، سهل التنفيذ	أنا بحاجة لقراءة الوثائق
الكيانات	إنشاء نموذج كائن إنشاء برنامج نصي DB الفئات الأساسية للكيانات	ميزات إضافية للعمل مع البيانات
مستودعات	EntityManager المشاهدات	داتاماناغر
الخدمات	حبوب المكتب إدارة المعاملات إدارة المستخدم	واجهة المثابرة (والفئة)
وحدات تحكم	وحدات تحكم REST الأصلية عناوين URL REST القياسية	نشر الخدمة
واجهة	النماذج القياسية للعمل مع البيانات	أنماط ومكونات مخصصة

بالطبع ، لا تستخدم Pet Clinic جميع ميزات CUBA ، ويمكن العثور على قائمة كاملة بميزات النظام الأساسي على الموقع ، وهناك يمكنك أيضًا العثور على أمثلة برمجية لحل المشكلات النموذجية التي تنشأ عند تطوير تطبيقات المؤسسة.

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

إيجابيات واحد! هل هناك عيوب؟

بالطبع هناك ، لا توجد أطر مثالية. إنهم ليسوا حرجين ، ولكن في البداية ، عندما بدأت العمل مع CUBA ، كان هناك بعض الانزعاج. لكن قيمة WTF / m لم تكن باهظة.

• بالنسبة لمنصة CUBA ، هناك IDE يبسط الإنشاء الأولي للمشروع. التبديل بين الاستوديو و IDEA مزعج قليلاً في البداية. الخبر السار هو أن هناك إصدارًا تجريبيًا من CLI ، ولا تحتاج إلى تشغيل الاستوديو لإنشاء هيكل المشروع ، وأيضًا - سيكون الإصدار التالي من CUBA Studio مكونًا إضافيًا لـ Intellij IDEA. لا مزيد من التبديل.
  
• يحتوي CUBA على ملفات XML أكثر من متوسط ​​تطبيق Spring Boot ، وذلك لأن تهيئة السياق في CUBA تتم بطريقتها الخاصة. الآن النضال جار لتقليل كمية XML ، ننتقل إلى التعليقات التوضيحية حيثما أمكن.
  
• لا توجد عناوين URL "قابلة للقراءة" لنماذج واجهة المستخدم. من الممكن الوصول إلى النماذج من خلال روابط للشاشات ، ولكنها ليست سهلة الاستخدام للغاية.
  
• للعمل مع البيانات ، تحتاج إلى استخدام DataManager وطرق العرض و EntityManager ، وليس Spring JPA أو JDBC (ولكن واجهات برمجة التطبيقات هذه متاحة أيضًا إذا لزم الأمر).
  
• يعمل CUBA بشكل أفضل مع قواعد البيانات العلائقية كمستودع للبيانات. بالنسبة إلى NoSQL ، سيكون عليك استخدام مكتبات الوصول لهذه المستودعات وكتابة طبقة المستودع الخاصة بك. ولكن هذا هو نفس مقدار العمل عند تطوير تطبيق بدون CUBA ، في رأيي.
  

المجموع

إذا كانت هناك مهمة تطوير تطبيق يستخدم قاعدة بيانات علائقية كمستودع بيانات ويركز على العمل مع البيانات بتنسيق جدول ، فيمكن أن يكون CUBA خيارًا جيدًا ، لأنه:

1. كوبا شفافة. رمز المصدر متاح ، يمكن تصحيح أي طريقة.
   
2. CUBA قابل للتوسيع (إلى حدود معروفة ، بالطبع). يمكنك ترث أي فئة فائدة تقريبًا ووضعها على النظام الأساسي ، وإنشاء REST API الخاص بك ، واستخدام إطار العمل المفضل لديك لواجهة المستخدم. تم إنشاء CUBA بحيث يمكنك بسهولة تكييف الحلول لأي عميل. هناك مقال جيد حول إمكانية توسيع النظام الأساسي.
   
3. CUBA هو الربيع. 80٪ من كود الخادم الخاص بك سيكون مجرد تطبيق Spring.
   
4. بداية سريعة. سيكون لديك تطبيق كامل مع لوحة إدارة بعد إنشاء الكيان الأول وشاشة للعمل معه.
   
5. تم بالفعل حل العديد من المهام الروتينية في النظام الأساسي.
   

لذلك ، مع CUBA ، يمكنك توفير الوقت لكتابة رمز "خدمة" رتيب والتركيز على كتابة التعليمات البرمجية لحل مشاكل العمل. ونعم ، نحن في Haulmont أنفسنا نستخدم CUBA لتطوير كل من المنتجات المعبأة والمخصصة.