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

في هذه المقالة، لن أخبرك بكيفية تشغيل مشروع Spring وتشغيله في 5 دقائق باستخدام الكود الخاص بي. سأكتب فقط الأساسيات - الأشياء التي قد تجهلها ولا تزال تنشئ مشروعًا. لكن في هذه المقالة، مازلت لا تفهم ما يحدث، والأهم من ذلك، لماذا.

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

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

بناء

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

https://docs.spring.io/spring/docs/4.3.26.RELEASE/spring-framework-reference/htmlsingle/
الشكل 2.1. نظرة عامة على إطار الربيع

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

• الدخول الى البيانات
• ويب
• جوهر
• و اكثر

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

لماذا تمتلك Java إطار الربيع؟

حسنًا، إلى جانب كونه عصريًا ورائعًا وجديدًا، يمكنني أن أقول الآن أنه بمجرد حصولك على قدر صغير من المهارة في استخدام Spring، ستفهم كيف أن هناك جميع أنواع العمل التي لم تعد لديك للقيام به، ومقدار العمل الذي يأخذه الربيع على عاتقه. يمكنك كتابة بضع عشرات من أسطر إعدادات التكوين وكتابة فصلين دراسيين، وينتهي بك الأمر بمشروع عملي. ولكن بمجرد أن تبدأ في التساؤل عن مقدار الأشياء الموجودة تحت الغطاء، ومقدار العمل الذي يتم إنجازه، ومقدار التعليمات البرمجية التي سيتعين عليك كتابتها إذا كنت ستنفذ نفس المشروع استنادًا إلى servlets أو مآخذ التوصيل البسيطة وجافا النقية، سوف يقف شعرك على نهايته :) حتى أن الربيع يوصف بأنه نوع من السحر. تختبر ذلك عندما ترى أن كل شيء يعمل، ولكن لديك أيضًا فكرة تقريبية عن كيفية وحجم العمل الذي يحدث خلف الكواليس - لذلك يبدو أن هناك بالفعل نوعًا من السحر في العمل :) من الأسهل أن نطلق عليه سحرًا بدلاً من محاولة شرح كيفية ترابط كل شيء. :) الحجة الثانية لصالح دراسة Spring هي أن ما يقرب من 90٪ من فرص العمل للمطورين المبتدئين (استنادًا إلى ملاحظاتي الشخصية) تتطلب معرفة أو على الأقل فكرة عامة عما تقدمه Spring's و ووحداته Dataللمطورين Web MVCالمتطورين Security:) لكن اليوم يدور حول الأساسيات فقط.

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

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

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

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

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

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

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

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

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

هناك ثلاث طرق رئيسية لتكوين التطبيق ، أي طرق إخبار Spring بالكائنات التي نحتاجها بالضبط:

1. ملفات تكوين XML
2. التكوين القائم على جافا
3. التكوين التلقائي

يعطي منشئو Spring الأولوية لهم بهذا الترتيب:

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

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