Spring Boot 2.0 - بنية المشروع وأفضل الممارسات (الجزء الثاني)

استمرارًا للجزء الأول من السلسلة على Spring Boot v2.0 ، هذا هو الجزء الثاني والختام حيث سنقوم بالاطلاع على هيكل مشروع التطبيق جنبًا إلى جنب مع بعض المقتطفات المهمة وأفضل الممارسات التي يجب أخذها في الاعتبار أثناء القيام بالتطوير المستند إلى Spring Boot .

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

مصدر الرمز

يمكن استنساخ الكود المصدري لمجموعة أدوات المبتدئين هذه من مستودع جيثب التالي:

هيكل التطبيق

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

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

النماذج و DTOs

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

تتيح لنا DTOs نقل البيانات التي نحتاج إلى مشاركتها فقط مع واجهة المستخدم وليس كائن النموذج بالكامل الذي قد جمعناه باستخدام العديد من الكائنات الفرعية واستمر في قاعدة البيانات. يمكن معالجة تعيين النماذج إلى DTOs باستخدام الأداة المساعدة ModelMapper ، ولكن من المفيد فقط عندما يكون DTO الخاص بك مشابهًا تقريبًا (حرفيًا) للنماذج المعنية التي لا تمثل دائمًا الحالة ، ولذا فإنني أفضل استخدام فئات معين معين. يمكنك العثور على بعض الأمثلة ضمن حزمة "dto / mapper".

على سبيل المثال ، دعونا نلقي نظرة على كيفية تنظيم نموذج Trip.java لدينا:

Trip.java

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

TripDto.java

كما ذكرت سابقًا ، لا يُقصد من DTOs أن تكون الصورة المتطابقة لنظرائها النموذجيين ، بل يجب أن تكون انعكاسًا لما تتطلبه واجهة المستخدم أو استجابة api. في هذه الحالة ، لم يكن هناك أي معنى في تكوين علاقة تكوينية بين رحلة وحافلة أو وكالة أو محطات توقف ، بل يمكن لمفاتيحها الأساسية القيام بالخدعة بالفعل. لا يؤدي هذا إلى فصل هذه DTOs فقط ، بل إنه يقلل أيضًا من الحجم الإجمالي لحزمة الاستجابة التي ستنتقل عبر HTTP من الخادم إلى العميل.

يمكن أن يكون السؤال التالي هو كيفية تحويل نموذج POJO إلى DTO ، فهناك أكثر من طريقة للقيام بذلك ، لكنني أفضل أن أكون صريحًا و DIY على النحو التالي:

الخدمات و DAOs

كائنات الوصول إلى البيانات (DAOs) موجودة في حزمة المخزون. إنها كلها امتدادات لواجهة MongoRepository تساعد طبقة الخدمة على الاستمرار واستعادة البيانات من MongoDB.

يتم تعريف طبقة الخدمة ضمن حزمة الخدمة ، بالنظر إلى دراسة الحالة الحالية ، فمن المنطقي إنشاء خدمتين أساسيتين:

  1. خدمة المستخدم و
  2. BusReservationService

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

UserService.java

BusReservationService.java

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

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

لتوضيح النهج المذكور أعلاه ، دعنا نأخذ مثالاً على عملية خدمة "updateProfile" تُستخدم لتحديث معلومات المستخدم. تعريف الطريقة تبدو كما يلي:

الأمان

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

يتم تكوين أمان الويب و apis في نفس الفئة MultiHttpSecurityConfig.java. يحتوي على فئتين ثابتتين يمتدان من WebSecurityConfigurerAdapter ، مما يتيح لنا تكوين أمان http للطلبات الواردة.

يتيح التعليق التوضيحيOrder فحص الطلبات من خلال التكوينات المختلفة بالترتيب المحدد. لذلك يمر طلب واجهة برمجة التطبيقات (API) عبر ApiWebSecurityConfigurationAdapter ويتم امتصاصه هناك ، ومع ذلك فإن طلب المشرف يمر أولاً به ولكن لأنه لا يتطابق مع المعايير ، يحاول Spring Security جعله يمر عبر التكوين التالي بترتيب أعلى فوري والذي في هذه الحالة هو FormLoginWebSecurityConfigurerAdapter.

يتعين على طلبات واجهة برمجة التطبيقات (API) الانتقال إلى ApiJWTAuthenticationFilter و ApiJWTAuthorizationFilter المسؤولة عن إنشاء الرمز المميز JWT والتحقق منه الصادر في وقت تسجيل الدخول. إذا كنت تتساءل عن عنوان URL الذي يجب استخدامه لمصادقة واجهة برمجة التطبيقات (تسجيل الدخول) فهو هنا:

HTTP: // المضيف المحلي: 8080 / المعهد / المصادقة

وإذا كنت تتساءل عن كيفية تكوين هذا ، فإن الإجابة تكمن في فئة ApiJWTAuthenticationFilter ، فإن مُنشئها يحتوي على المعلومات التالية مشفرة:

this.setRequiresAuthenticationRequestMatcher (جديد AntPathRequestMatcher ("/ api / auth" ، "POST")) ؛

هذا يخبر AbstractAuthenticationProcessingFilter لربط AuthenticationRequestMatcher مع المسار "/ api / auth" لطلبات API.

يُسمح بتطبيق المسؤول فقط لأولئك المستخدمين الذين يكون دورهم "ADMIN". يتم تشفير جميع كلمات المرور باستخدام BCryptPasswordEncoder ولا يمكننا أن نرى قيمتها الفعلية بمجرد تخزينها في قاعدة البيانات.

التحكم

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

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

تعمل وحدات تحكم لوحة الإدارة على مفهوم Spring WebMVC. يستجيبون لطلبات الويب الواردة باستخدام كائنات ModelAndView لـ Spring التي تحتوي على البيانات ليتم عرضها على طرق العرض / النماذج المعنية واسم طريقة العرض المراد تقديمها ، مثال على ذلك من فئة DashboardController كما يلي:

أوامر الطلب والنموذج

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

تعطينا كائنات الطلب وأوامر النموذج طريقة لتطبيق مستوى إضافي من عمليات التحقق على الطلبات الواردة قبل تحويلها إلى DTOs التي تنقل المعلومات الصحيحة إلى طبقة الخدمة للاستمرار واستعادة البيانات. يمكننا استخدام DTOs هنا ويفضل بعض المطورين هذا النهج لأنه يقلل من بعض الفئات الإضافية ، ولكن عادةً ما أفضّل الحفاظ على منطق التحقق من الصحة منفصلًا عن كائنات النقل ، وبالتالي أميل إلى استخدام كائنات الطلب / الأمر في المقدمة.

يظهر نموذج BusFormCommand بناءً على نموذج أمر كما يلي:

ومثال لطلب تم إرساله عبر واجهة برمجة التطبيقات ، BookTicketRequest كالتالي:

يتم تجميع الموارد الثابتة تحت دليل الموارد. يمكن العثور على جميع كائنات واجهة المستخدم وجوانب التصميم الخاصة بها هنا.

لومبوك

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

تضمين التغريدة

لا تكتب public int getFoo () {return foo؛} مرة أخرى.

@إلى سلسلة

لا حاجة لبدء مصحح الأخطاء لرؤية حقولك: فقط دع lombok يقوم بإنشاء سلسلة من أجلك!

EqualsAndHashCode

أصبحت المساواة سهلة: يولد hashCode ويساوي التطبيقات من حقول الكائن الخاص بك ..

@البيانات

الكل معًا الآن: اختصار لـToString و @ EqualsAndHashCode و @ Get في جميع الحقول وSetter في جميع الحقول غير النهائية و

RequiredArgsConstructor!

في جوهرها ، شيء مطول مثل:

يمكن كتابتها ببساطة على النحو التالي:

يمكنك أن ترى الفرق جيدًا ، ليس فقط في وقت لاحق يبدو أكثر نظافة ، فقد نزلنا من 59 سطرًا من نظام POJO الممل إلى ملف فئة جافا مكون من 8 أسطر.

استجابة API ومعالجة الاستثناء

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

  1. EntityType و
  2. ExceptionType

يحتوي تعداد EntityType على جميع أسماء الكيانات التي نستخدمها في النظام من أجل الثبات وتلك التي يمكن أن تؤدي إلى استثناء وقت التشغيل. يتكون التعداد ExceptionType من استثناءات مستوى الكيان المختلفة مثل استثناءات EntityNotFound و DuplicateEntity.

تحتوي فئة BRSException على فئتين ثابتتين هما EntityNotFoundException و DuplicateEntityException وهما الاستثناءان الأكثر انتشارًا من طبقة الخدمة. كما أنه يحتوي على مجموعة من الأساليب overloaded ، والتي تأخذ EntityType و ExceptionType والوسيطات لتخرج برسالة منسقة يوجد قالبها تحت ملف custom.properties.

باستخدام هذه الفئة ، تمكنت من تمكين طبقة الخدمات بأكملها لرمي مجموعة متنوعة من استثناءات الكيان بطريقة موحدة دون تشويش قاعدة الكود بكل أنواع استثناءات الكيانات NOT_FOUND و DUPLICATE.

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

استثناء رمي (USER، ENTITY_NOT_FOUND، userDto.getEmail ())؛

ينتج عن هذا تجميع أسماء عنصري التعداد USER ("المستخدم") و ENTITY_NOT_FOUND ("not.found") والخروج بمستخدم رئيسي. not.found الموجود في ملفات custom.properties كما يلي:

user.not.found = المستخدم المطلوب بالبريد الإلكتروني - {0} غير موجود.

ببساطة عن طريق استبدال {0} param بعنوان البريد الإلكتروني المتضمن في الاستثناء الذي تم طرحه ، يمكنك الحصول على رسالة منسقة جيدًا ليتم عرضها للمستخدم أو إعادتها كرد على مكالمة REST API. تعريف فئة BRSException هو كما يلي:

جزء هام آخر من هذا الإطار المصغر هو فئة CustomResponseEntityExceptionHandler التي تبدو كما يلي:

هذه الفئة تهتم RuntimeExceptions قبل إرسال استجابة لطلبات API. في نصيحة تحكم بالتحقق مما إذا كان استدعاء طبقة خدمة أدى إلى EntityNotFoundException أو DuplicateEntityException وإرسال استجابة مناسبة إلى المتصل.

أخيرًا ، يتم إرسال استجابة API جميعها بطريقة موحدة باستخدام فئة الاستجابة الموجودة في حزمة dto / response. تسمح لنا هذه الفئة بإنشاء كائنات موحدة تؤدي إلى استجابة كما هو موضح أدناه (هذا الرد هو استجابة لـ api / v1 / booking / stop ”api):

{
 "الحالة": "موافق" ،
 "الحمولة": [
   {
    "الكود": "STPA" ،
    "الاسم": "إيقاف A" ،
    "التفاصيل": "بالقرب من التلال"
   }،
   {
    "الكود": "STPB" ،
    "الاسم": "إيقاف B" ،
    "التفاصيل": "بالقرب من النهر"
   }
 ]
}

وعندما يكون هناك استثناء (على سبيل المثال البحث عن رحلة بين محطتين غير مرتبطتين بأي حافلة) ، يتم إرسال الردود التالية (نتيجة لطلب الحصول على api / v1 / booking / tripsbystops):

{
  "الحالة": "NOT_FOUND" ،
  "الأخطاء": "لا توجد رحلات بين محطة التوقف -" STPD "وتوقف الوجهة -" STPC "متاحة في الوقت الحالي."
}
{
  "الحالة": "NOT_FOUND" ،
  "أخطاء":
  {
    "الطابع الزمني": "2019–03–13T07: 47: 10.990 + 0000" ،
    "message": "توقف مطلوب مع رمز - STPF غير موجود."
  }
}

كما يمكنك ملاحظة ، كلا النوعين من الردود ، واحدة مع HTTP-200 والأخرى مع HTTP-404 ، حمولة الاستجابة لا تغير هيكلها ويمكن أن يقبل إطار الاتصال بشكل أعمى الاستجابة مع العلم أن هناك حالة وخطأ أو حقل البيانات الفعلية في كائن JSON.

وثائق API

من المهم توثيق عملك (كما هو حال تطويره) والتأكد من توفر واجهة برمجة تطبيقات Spring Boot بطريقة يمكن قراءتها للفرق الأمامية (الداخلية) أو العملاء الخارجيين. أداة وثائق API المستخدمة في مجموعة أدوات البدء هذه هي Swagger2 ، ويمكنك فتحها داخل متصفح على عنوان url التالي -

HTTP: // المضيف المحلي: 8080 / اختيال-ui.html

سيقدم لك واجهة مستخدم جيدة التنظيم تحتوي على اثنين من المواصفات:

1. المستخدم
2. BRS

يمكنك استخدام مواصفات المستخدم لتنفيذ api لتسجيل الدخول لإنشاء الرمز المميز لـ Bearer. عندئذٍ يجب تطبيق الرمز المميز في نافذة "تخويل" المنبثقة التي ستطبقها افتراضيًا على جميع أنظمة المعلومات المؤمنة المضمونة (الحصول على كل منهما ونشره). يرجى مراعاة أنه يجب عليك إلحاق كلمة "Bearer" متبوعة بمسافة ، أمام الرمز المميز قبل تطبيقها في مربع حوار التخويل.

تكوين Swagger يتم الاعتناء به بواسطة BrsConfiguration للفئة. لقد قمت بتحديد اثنين من المواصفات هناك بمساعدة طرق "swaggerBRSApi" و "swaggerUserApi". نظرًا لأن قسم تسجيل الدخول يتم العناية به افتراضيًا بواسطة Spring Security ، فإننا لا نحاول الكشف عن apis بشكل ضمني مثل باقي أجزاء apis المحددة في النظام ، وللسبب نفسه ، قمت بتعريف وحدة تحكم في حزمة التهيئة بالاسم "FakeController":

والغرض منه هو تسهيل إنشاء مستندات التبديل لتسجيل الدخول وتسجيل الخروج ، ولن تظهر أبدًا خلال دورة حياة التطبيق حيث يتم التعامل مع "/ api / auth" api بواسطة عوامل تصفية الأمان المحددة في قاعدة الشفرة. فيما يلي بعض لقطات الشاشة لمساعدتك على تصور الأشياء بشكل أفضل قليلاً:

اختيال UI/ api / مصادقة تسجيل الدخول ، مجاملة FakeControllerتفويض الحوار لتسجيل الرموز المميزة لـ Bearerواجهات برمجة التطبيقات BRSواجهات برمجة التطبيقات BRS المدرجة

لاستخدام Swagger UI وتنفيذ واجهات برمجة التطبيقات الآمنة ، ستحتاج أولاً إلى تشغيل "/ api / auth" من مواصفات المستخدم وإنشاء رمز Bearer. بمجرد إصدار الرمز المميز ، يمكنك تسجيله في نافذة الإذن المأذون بها ثم الانتقال إلى مواصفات BRS لتنفيذ واجهات برمجة التطبيقات الآمنة. إذا لم تقم بتسجيل الرمز المميز ، فستستمر في تلقي خطأ HTTP 401.

قد تصادفك مشاكل أثناء تجربة Swagger-Ui لطلبات HTTP-GET التي لها هيئة ذات معلمات ، فلا تقلق ، إنها ليست خطأ التعليمات البرمجية ، فهي قرار Swagger بالتوقف عن دعم العوامل الأساسية لطلبات GET و DELETE . كحل مؤقت ، يمكنك نسخ طلب الضفيرة من swagger وتنفيذه داخل نافذة طرفية ويجب أن يكون ذلك جيدًا أو قد تختار الذهاب إلى Postman أو أداة مشابهة لأنها لا تفرض (بعد) فرض قيود مشددة. في وجهات نظري ، طالما أن مواصفات واجهة برمجة التطبيقات المفتوحة لا تقيد العوامل الأساسية في طلبات GET ، فإن الأدوات مثل Swagger لا ينبغي أن تكون كذلك ، ومع ذلك فهي دعوة يحتاجون إليها وليس لنا كمطورين.

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

تم تصميم واجهة المستخدم لبوابة المشرف باستخدام تصميم المواد بمساعدة Bootstrap ومفهوم تطبيق الويب المستجيب. يتم تقديم واجهة المستخدم من جانب الخادم باستخدام قوالب Thymeleaf (محرك التمجيد المفضل في Spring).

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

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

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

تم تصميم تخطيط بوابة المشرف على النحو التالي:

بلوق مثل تخطيط

تخدم المناطق الفردية في هذا التخطيط الغرض التالي:

  • الرأس: يتم استخدام هذا الجزء للواردات الثابتة (CSS و JavaScript) والعنوان وعلامات التعريف.
  • التنقل: شريط التنقل مع ملف تعريف المستخدم في أعلى اليمين.
  • المحتوى: العنصر النائب للمحتوى الذي سيتم استبداله بالصفحة المطلوبة.
  • الشريط الجانبي: شريط جانبي للحصول على معلومات إضافية.
  • تذييل الصفحة: منطقة التذييل التي توفر معلومات حقوق النشر.

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

  • لوحة القيادة
  • وكالة
  • حافلة
  • رحلة قصيرة
  • الملف الشخصي

أيضًا ، تم تصميم صفحة خطأ لأي استثناء غير معالج باسم "error.html". تم تصميم صفحات تسجيل الدخول والاشتراك بشكل منفصل عن البوابة التي يمكن للمستخدم الذي قام بتسجيل الدخول الدخول إليها.

تشغيل الخادم محليا

لتتمكن من تشغيل تطبيق Spring Boot هذا ، ستحتاج أولاً إلى بنائه. لإنشاء حزمة Spring Boot وحزمها في ملف Jar واحد قابل للتنفيذ باستخدام Maven ، استخدم الأمر أدناه. ستحتاج إلى تشغيله من مجلد المشروع الذي يحتوي على ملف pom.xml.

حزمة مخضرم

أو يمكنك أيضا استخدام

تثبيت MVN نظيفة

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

java -jar target / springboot-starterkit-0.0.1-SNAPSHOT.jar

يمكنك أيضًا استخدام البرنامج المساعد Maven لتشغيل التطبيق. استخدم المثال أدناه لتشغيل تطبيق Spring Boot مع البرنامج المساعد Maven:

MVN الربيع التمهيد: المدى

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

HTTP: // المضيف المحلي: 8080

ويمكن الوصول إلى واجهات برمجة تطبيقات REST عبر المسار الأساسي التالي:

HTTP: // المضيف المحلي: 8080 / المعهد /

بعض نقاط النهاية المهمة لـ api هي كما يلي:

  • http: // localhost: 8080 / api / v1 / user / signup (HTTP: POST)
  • http: // localhost: 8080 / api / auth (HTTP: POST)
  • http: // localhost: 8080 / api / v1 / booking / stop (HTTP: GET)
  • http: // localhost: 8080 / api / v1 / booking / tripsbystops (HTTP: GET)
  • http: // localhost: 8080 / api / v1 / booking / tripschedules (HTTP: GET)
  • http: // localhost: 8080 / api / v1 / booking / bookticket (HTTP: POST)

حاوية عامل الميناء

الرجاء استخدام الأمر التالي لإنشاء صورة الحاوية:

عامل بناء بناء -t الربيع / starterkit.

والأمر التالي لتشغيل الحاوية:

تشغيل عامل ميناء - 8080: 8080 الربيع / starterkit

يرجى ملاحظة عند إنشاء صورة الحاوية وإذا كان mongodb يعمل محليًا على نظامك ، فستحتاج إلى تقديم عنوان IP الخاص بنظامك (أو عنوان IP لقاعدة بيانات السحابة المستضافة) في ملف application.properties (أو envars) لتتمكن من الاتصال إلى قاعدة البيانات من داخل الحاوية.

خاتمة

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

آمل أن تكون هذه السلسلة من مقالتين قد ساعدتكم في تحسين مجموعة مهاراتك في Spring Boot وأن تكون قد قدمت لك منصة قوية للبدء في كتابة تطبيق Spring Boot التالي.

سعيد ترميز الجميع!

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

هل تعلم أنك يمكن أن تتخلى عن 50 التصفيق؟