أساسيات Spring Boot

ما هو Spring Boot؟

18 دقيقة الدرس 1 من 13

ما هو Spring Boot؟

إذا أتممت دروس Spring IoC وحقن التبعيات في هذه الدورة، فأنت تعرف بالفعل قوة إطار عمل Spring: منظومة ناضجة ومُختبرة ميدانيًا لبناء تطبيقات Java. وتعرف أيضًا ثمنه — ملفات XML وعشرات تعريفات الحبوب (beans) وضبط مسح المكونات وتوصيل مدير المعاملات، وكمٌّ مُحبِط من الوقت يضيع قبل أن يُلقي تطبيقك تحيةً واحدة. أُنشئ Spring Boot تحديدًا للقضاء على هذا الثمن.

في هذا الدرس ستفهم ماهية Spring Boot فعليًا (وما ليس عليه)، وكيف يرتبط بإطار عمل Spring الذي تعرفه بالفعل، ولماذا تتيح لك فلسفة التصميم القائمة على الاصطلاح بدلًا من التهيئة (Convention Over Configuration) الانتقال من مشروع فارغ إلى تطبيق جاهز للإنتاج في دقائق لا ساعات.

Spring Boot ليس بديلًا عن Spring

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

كل تعليق توضيحي (annotation) تعلمته — @Component و@Service و@Autowired و@Transactional — يعمل بصورة متطابقة في تطبيق Spring Boot، لأن تحته في النهاية نفس ApplicationContext لـ Spring يدير حبوبك (beans). ما يضيفه Boot هو طبقة تقرر كيفية تهيئة هذه المكونات حتى لا تضطر أنت لذلك.

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

المشكلة التي يحلها Spring Boot

لتقدير ما يمنحك إياه Boot، تذكّر ما كان يتطلبه تطبيق Spring ويب التقليدي قبل ظهور Boot:

ملف وصف نشر web.xml لتسجيل DispatcherServlet.
ملف XML أو فئة @Configuration لتعريف DataSource وPlatformTransactionManager وViewResolver وEntityManagerFactory.
حاوية servlet (Tomcat أو Jetty) مثبّتة بشكل منفصل ومُهيَّأة لنشر ملف WAR.
محاذاة إصدارات التبعيات يدويًا — التأكد من توافق Spring MVC 5.x مع Hibernate 5.x الذي يستلزم بدوره إصدارًا بعينه من مشغّل JDBC، وهكذا.

لم يكن في أيٍّ من هذه التهيئة ما يُعبّر عن مجال عملك الفعلي. كانت كلها حفلًا من الإجراءات التحتية المكررة. يُلغيها Spring Boot من خلال ثلاث آليات متشابكة: المبادئ (Starters) والتهيئة التلقائية (Auto-Configuration) والخادم المدمج (Embedded Server).

الاصطلاح بدلًا من التهيئة

الفلسفة التوجيهية مستعارة من Ruby on Rails ومتكررة في جميع أنحاء Boot: تُفضَّل الاصطلاحات (الإعدادات الافتراضية المنطقية) على اشتراط التهيئة الصريحة. إذا أضفت مشغّل PostgreSQL إلى مسار الفئات (classpath)، يفترض Boot أنك تريد DataSource يشير إلى localhost:5432 — ما لم تقل خلاف ذلك. وإذا أضفت Spring Security، يحمي Boot كل نقطة نهاية — ما لم تقل خلاف ذلك. كل اصطلاح هو مخرج طوارئ: تكفي خاصية واحدة أو تعريف @Bean واحد لاستبدال الإعداد الافتراضي.

هذا نقيض الإطار ذي اللوح الأبيض. مع Boot تبدأ من "كل شيء مُهيَّأ" وتُعطّل الأشياء انتقائيًا أو تتجاوزها، بدلًا من البدء من لا شيء وتجميع كل قطعة.

تطبيق Spring Boot 3 في أدنى صورة

إليك الكود الكامل لخادم HTTP يعمل في Spring Boot 3. بلا XML. بلا تثبيت Tomcat خارجي. بلا تعبئة WAR.

// pom.xml parent (سطر واحد يستورد أكثر من 200 إصدار تبعية مُدارة)
// <parent>
//     <groupId>org.springframework.boot</groupId>
//     <artifactId>spring-boot-starter-parent</artifactId>
//     <version>3.3.0</version>
// </parent>

package com.example.demo;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@SpringBootApplication          // (1) ثلاثة تعليقات توضيحية في واحد
@RestController
public class DemoApplication {

    public static void main(String[] args) {
        SpringApplication.run(DemoApplication.class, args);   // (2)
    }

    @GetMapping("/hello")
    public String hello() {
        return "Hello from Spring Boot 3!";
    }
}

شغّل هذا بـ mvn spring-boot:run وسيكون لديك خادم مباشر على http://localhost:8080/hello. لنتتبع ما حدث.

ما الذي يفعله @SpringBootApplication

@SpringBootApplication تعليق توضيحي مُركَّب — اختصار لثلاثة تعليقات توضيحية تُطبَّق في آنٍ واحد:

@SpringBootConfiguration — يُعلّم هذه الفئة بوصفها مصدر @Configuration لـ Spring (مكافئ لـ @Configuration في Spring العادي).
@ComponentScan — يُمكّن مسح المكونات انطلاقًا من حزمة الفئة المُعلَّمة وما دونها. أي @Component أو @Service أو @Repository أو @Controller في الحزم الفرعية يُلتقط تلقائيًا.
@EnableAutoConfiguration — يُطلق آلية التهيئة التلقائية في Boot: يفحص Spring Boot مسار الفئات بحثًا عن المكتبات المعروفة ويصل الإعدادات الافتراضية المنطقية لكل منها.

الانضباط في الحزم مهم: لأن @ComponentScan ينطلق من حزمة الفئة المُعلَّمة، ضع فئتك الرئيسية في الحزمة الجذر للمشروع (مثل com.example.demo). الحزم الفرعية مثل com.example.demo.web وcom.example.demo.service ستُمسح تلقائيًا. أي فئة خارج هذا التسلسل الهرمي ستكون غير مرئية لـ Boot.

SpringApplication.run — ما يحدث عند بدء التشغيل

استدعاء SpringApplication.run(DemoApplication.class, args) يُشغّل التطبيق في تسلسل منتظم:

ينشئ نسخة من SpringApplication ويكشف نوع التطبيق (قائم على servlet أو تفاعلي أو لا شيء) من مسار الفئات.
يُحمّل مُهيِّئات ApplicationContext والمستمعين (خطافات يمكنك استخدامها للتخصيص قبل إنشاء السياق).
يُنشئ ApplicationContext ويُشغّل التهيئة التلقائية.
يبدأ خادم Tomcat المدمج (أو Jetty أو Undertow).
يُطلق ApplicationReadyEvent — الإشارة بأن التطبيق مباشر ويقبل الطلبات.

يكتمل التسلسل كله في أقل من ثانيتين على حاسوب حديث. قارن ذلك بنشر WAR على خادم تطبيقات خارجي.

Spring Boot 3 ومساحة أسماء Jakarta EE

تفصيل هجرة مهم إذا كنت تُرقّي كودًا قديمًا: Spring Boot 3 مبني على Spring Framework 6، الذي أتمّ الهجرة من مساحة الأسماء javax.* إلى jakarta.*. التعليقات التوضيحية مثل @NotNull تقع الآن في jakarta.validation.constraints، وواجهة برمجة Servlet في jakarta.servlet، وتعليقات JPA في jakarta.persistence.

javax.* مقابل jakarta.*: إذا نسخت مقتطفًا من درس سابق لـ Boot 3 ويستورد javax.persistence.Entity أو javax.validation.constraints.NotNull، فهذه الاستيرادات ستفشل في التحويل البرمجي تحت Spring Boot 3. استبدل كل بادئة javax. بـ jakarta.. يمكن لبيئة التطوير المتكاملة (IDE) عادةً القيام بذلك تلقائيًا.

Boot مقابل Spring العادي — مقارنة جنبًا إلى جنب

لجعل التباين ملموسًا، إليك ما يبدو عليه توصيل DataSource في كل أسلوب:

Spring العادي (التهيئة اليدوية):

@Configuration
public class DataSourceConfig {

    @Bean
    public DataSource dataSource() {
        HikariConfig cfg = new HikariConfig();
        cfg.setJdbcUrl("jdbc:postgresql://localhost:5432/mydb");
        cfg.setUsername("user");
        cfg.setPassword("pass");
        cfg.setMaximumPoolSize(10);
        return new HikariDataSource(cfg);
    }

    @Bean
    public JdbcTemplate jdbcTemplate(DataSource ds) {
        return new JdbcTemplate(ds);
    }
}

Spring Boot (الاصطلاح بدلًا من التهيئة):

# application.properties — هذه التهيئة بأكملها المطلوبة
spring.datasource.url=jdbc:postgresql://localhost:5432/mydb
spring.datasource.username=user
spring.datasource.password=pass

يكتشف Boot وجود HikariCP في مسار الفئات، يقرأ الخصائص الثلاث، ينشئ HikariDataSource، يسجّله بوصفه حبة DataSource الأساسية، ويسجّل أيضًا حبة JdbcTemplate مدعومة بها — كل ذلك تلقائيًا. يكفي كود التطبيق أن يُعلّن @Autowired على JdbcTemplate وتعمل مباشرةً.

الخلاصة

Spring Boot هو طبقة التجميع الجاهزة للإنتاج لمنظومة Spring. لا يحل محل Spring؛ بل يُهيّئه نيابةً عنك باستخدام الاصطلاحات، حتى تتمكن من التركيز على منطق الأعمال من السطر الأول من الكود. الركائز الثلاث — المبادئ (Starters) (مجموعات التبعيات المنسّقة) والتهيئة التلقائية (توصيل الحبوب بحسب مسار الفئات) والخادم المدمج (لا حاجة لحاوية خارجية) — تعمل معًا لتحقيق هذا الوعد. في الدروس التالية ستتقن كل ركيزة بعمق، بدءًا بكيفية إنشاء مشروع Spring Boot وما الذي يحتوي عليه المبدأ (starter) فعليًا.