الربيع للكسالى. الأساسيات والمفاهيم الأساسية والأمثلة مع التعليمات البرمجية. الجزء 1

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

ما هو إطار الربيع؟

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

بناء

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

• الدخول الى البيانات؛
• الويب؛
• جوهر؛
• و اخرين.

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

لماذا الربيع في جاوة؟

حسنًا، إلى جانب حقيقة أنها عصرية وأنيقة وشبابية، يمكنني أن أقول على الفور أنه بمجرد إتقانها ولو قليلاً، ستفهم مقدار العمل المختلف الذي لا يتعين عليك القيام به الآن، ومقدار الربيع يأخذ على. يمكنك كتابة بضع عشرات من أسطر التكوينات، وكتابة فصلين دراسيين - وستحصل على مشروع عمل. ولكن بمجرد أن تبدأ في التفكير في مقدار ما هو موجود "تحت الغطاء"، ومقدار العمل الذي يتم إنجازه، ومقدار التعليمات البرمجية التي يجب كتابتها إذا قمت بتنفيذ نفس المشروع على servlets العارية أو على المقابس وجافا النقية - شعرك يقف :) حتى أن هناك تعبيرًا مثل "سحر" الربيع. يحدث هذا عندما ترى أن كل شيء يعمل، لكنك تقدر تقريبًا مقدار ما يجب أن يحدث هناك لكي يعمل كل شيء وكيف يعمل كل شيء هناك - إذن يبدو أن كل هذا يحدث بفضل نوع من السحر حقًا)) من الأسهل أطلق على كل هذا سحرًا بدلاً من محاولة شرح كيفية ترابط كل شيء هناك. ابتسم data_ web-mvc_ security_ فقط الأساسيات.

دي / اللجنة الدولية

إذا حاولت قراءة شيء ما في فصل الربيع، فمن المحتمل أن أول ما صادفته هو هذه الأحرف: DI/IoC . الآن أوصي بشدة أن تأخذ استراحة من هذه المقالة وتقرأ هذه المقالة عن حبري ! IoC (انعكاس التحكم) - عكس التحكم. لقد ذكرت هذا بالفعل بشكل عابر عندما كتبت أنه عند استخدام مكتبة، فأنت بنفسك تكتب في الكود الخاص بك الطريقة التي سيتم استدعاء الكائن بها، وفي حالة الأطر، غالبًا ما يستدعي إطار العمل الكود الذي كتبته على اليمين لحظة. أي أنك هنا لم تعد تتحكم في عملية تنفيذ الكود/البرنامج، ولكن إطار العمل يقوم بذلك نيابةً عنك. لقد نقلت السيطرة إليه (انقلاب السيطرة). يُفهم DI إما على أنه عكس التبعية (انعكاس التبعية، أي محاولة عدم إجراء اتصالات صلبة بين الوحدات النمطية/الفئات الخاصة بك، حيث ترتبط فئة واحدة مباشرة بأخرى)، أو حقن التبعية (حقن التبعية، يحدث هذا عندما لا تكون كائنات cat تم إنشاؤها بواسطتك بشكل رئيسي ثم تقوم بتمريرها إلى أساليبك، ويقوم Spring بإنشائها لك، وتخبره فقط بشيء مثل "أريد الحصول على قطة هنا" ويقوم بتمريرها إليك بطريقتك). سنواجه في كثير من الأحيان الثانية في مقالات أخرى.

الفول والسياق

أحد المفاهيم الأساسية في الربيع هو الفول . في جوهرها، هو مجرد كائن من فئة معينة. لنفترض أننا نحتاج في برنامجنا إلى استخدام 3 كائنات: قطة وكلب وببغاء. ولدينا مجموعة من الفئات مع مجموعة من الأساليب، حيث نحتاج أحيانًا إلى قطة لطريقة، وكلب لطريقة أخرى، وأحيانًا سيكون لدينا طرق نحتاج فيها إلى قطة وببغاء (على سبيل المثال، طريقة لإطعام قطة، هيهي)، وفي بعض الطرق، ستكون هناك حاجة إلى العناصر الثلاثة جميعها. نعم، يمكننا أولاً إنشاء هذه الكائنات الثلاثة بشكل رئيسي، ثم تمريرها إلى فئاتنا، ومن داخل الفئات إلى الأساليب التي نحتاجها... وهكذا طوال البرنامج. وإذا تخيلنا أيضًا أننا نريد تغيير قائمة المعلمات المقبولة لأساليبنا بشكل دوري (حسنًا، قررنا إعادة كتابة شيء ما أو إضافة وظيفة) - فسيتعين علينا إجراء الكثير من التعديلات على الكود إذا أردنا ذلك تغيير شيء ما. الآن، ماذا لو تخيلنا أنه ليس لدينا 3، بل 300 من هذه الأشياء؟ البديل هو جمع كل هذه الكائنات في قائمة واحدة مشتركة من الكائنات ( List<Object> ) وتمريرها إلى جميع الأساليب، ومن داخل الأساليب نحصل على هذا الكائن أو ذاك الذي نحتاجه. ولكن ماذا لو تخيلنا أنه مع تقدم البرنامج، قد تتم إضافة بعض الكائنات إلى هذه القائمة، أو (الأسوأ) حذفها؟ ثم في جميع الطرق التي نسترجع بها الكائنات من القائمة حسب فهرسها، يمكن أن ينكسر كل شيء. ثم نقرر عدم تخزين القائمة، بل الخريطة، حيث سيكون المفتاح هو اسم الكائن الذي نحتاجه، وستكون القيمة هي الكائن نفسه، وبعد ذلك يمكننا الحصول على الكائنات التي نحتاجها منها ببساطة باسمها : get("parrot") وردًا على ذلك تلقينا كائن parrot أو على سبيل المثال، المفتاح هو فئة الكائن، والقيمة هي الكائن نفسه، ثم لم يعد بإمكاننا الإشارة إلى اسم الكائن، ولكن ببساطة فئة الكائن الذي نحتاجه، وهو أمر مناسب أيضًا. أو حتى كتابة نوع من الغلاف على الخريطة، حيث يمكنك إنشاء طرق بحيث يمكنك في بعض الحالات استرداد الكائنات حسب أسمائها، وفي حالات أخرى حسب الفئة. هذا ما حصلنا عليه من سياق تطبيق الربيع . السياق عبارة عن مجموعة من الفاصوليا (الكائنات). بالانتقال إلى السياق، يمكننا الحصول على الحبة (الكائن) التي نحتاجها من اسمها، على سبيل المثال، أو من نوعها، أو أي شيء آخر. بالإضافة إلى ذلك، يمكننا أن نطلب من Spring البحث عن الحبة التي نحتاجها في سياقها وتمريرها إلى طريقتنا. على سبيل المثال، إذا كان لدينا طريقة مثل هذا:

public void doSomething(Cat cat) {
    ...
}

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

public void doSomething(Cat cat, Parrot parrot) {
    ...
}

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

طرق تكوين التطبيق

هناك ثلاث طرق رئيسية لتكوين التطبيق (أي إخبار Spring بالكائنات التي نحتاجها للعمل):

1. باستخدام ملفات/تكوينات XML؛
2. باستخدام تكوينات جافا؛
3. التكوين التلقائي.

يقوم مطورو Spring بترتيبها حسب ترتيب الأولوية:

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

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