האביב מיועד לעצלנים. יסודות, מושגי יסוד ודוגמאות עם קוד. חלק 1

אנשים רבים, לאחר שקראו את המאמרים שלי על יצירת תבנית לפרויקט אינטרנט ועל יצירת שירות אינטרנט פשוט באמצעות servlets , תהו מתי אכתוב על אביב. לא רציתי, הצעתי לקרוא ספר (ואני עדיין אומר שספר עדיף על 10, או אפילו 100 מאמרים באינטרנט). אבל עכשיו החלטתי שלהסביר את אותו הדבר לאנשים שונים, אני מבלה יותר זמן מאשר אם ישבתי פעם אחת וכתבתי מאמר, ואז פשוט פרסמתי קישור אליו. אז אני כותב למען הקישור)). במאמר זה לא אכתוב איך לעשות פרויקט עבודה באביב ב-5 דקות בעקבות הדוגמה שלי. אכתוב רק על דברים בסיסיים שללא ידיעה בהם בהחלט אפשר להתחיל פרויקט, אבל מה קורה שם, ויותר חשוב, למה, לא יתברר.

מהי מסגרת אביב?

Spring Framework , או פשוט Spring , היא אחת המסגרות הפופולריות ביותר ליצירת יישומי אינטרנט ב-Java. מסגרת היא משהו שדומה לספרייה (אולי המונח הזה מוכר לך יותר), אבל יש נקודה אחת. באופן גס, באמצעות ספרייה אתה פשוט יוצר אובייקטים של המחלקות שנמצאות בה, קורא לשיטות שאתה צריך, וכך מקבלים את התוצאה שאתה צריך. כלומר, יש גישה יותר הכרחית: אתה מציין בבירור בתוכנית שלך באיזה רגע ספציפי אתה צריך ליצור איזה אובייקט, באיזה רגע אתה צריך לקרוא לשיטה ספציפית וכו'. עם מסגרות, הדברים קצת שונים. אתה פשוט כותב חלק מהמחלקות שלך, כותב שם חלק מההיגיון, והמסגרת עצמה יוצרת עבורך אובייקטים של המחלקות שלך וקוראת לשיטות. לרוב, המחלקות שלך מיישמות ממשקים מסוימים מהמסגרת או יורשים כמה מחלקות ממנה, וכך מקבלים חלק מהפונקציונליות שכבר נכתבה עבורך. אבל זה לא חייב להיות ככה. ב-Spring, למשל, הם מנסים להתרחק ככל האפשר מצימוד קפדני שכזה (כאשר השיעורים שלך תלויים ישירות במחלקות/ממשקים מסוימים מהמסגרת הזו), ומשתמשים בהערות למטרה זו. נחזור לנקודה זו בהמשך. אבל חשוב להבין ש- Spring הוא רק קבוצה של כמה מחלקות וממשקים שכבר נכתבו עבורכם :) אני גם רוצה לציין מיד ש-Spring יכול לשמש לא רק עבור יישומי אינטרנט, אלא גם עבור הקונסולה הנפוצה ביותר יישומים המוכרים כל כך לכולנו התוכניות והיום אפילו נכתוב משהו כזה.

מִבְנֶה

אבל אביב הוא לא מסגרת אחת ספציפית. זהו שם כללי למספר מסגרות קטנות, שכל אחת מהן עושה עבודה אחרת. כפי שאתה יכול לראות, לקפיץ יש מבנה מודולרי. זה מאפשר לנו לחבר רק את המודולים שאנחנו צריכים עבור האפליקציה שלנו ולא לחבר את אלה שכמובן לא נשתמש בהם. עד כמה שידוע לי, הגישה הזו היא שעזרה ל-Spring להתעלות על המתחרה שלה באותה תקופה (EJB) ולקחת את ההובלה. כי אפליקציות שמשתמשות ב-EJB משכו איתן הרבה תלות, ובאופן כללי הן התגלו כאיטיות ומגושמות. התמונה מראה שמסגרת האביב מורכבת ממספר מודולים:

• גישה למידע;
• אינטרנט;
• הליבה;
• ואחרים.

היום נכיר כמה מושגים של המודול הראשי, כגון: שעועית, הקשר ואחרים. כפי שאתה יכול לנחש, מודול הגישה לנתונים מכיל כלים לעבודה עם נתונים (בעיקר מסדי נתונים), אינטרנט - לעבודה ברשת (כולל ליצירת יישומי אינטרנט, עליהם נדון בהמשך). בנוסף, ישנה גם תשתית האביב שלמה: פרויקטים רבים אחרים שאינם כלולים רשמית במסגרת עצמה, אך משולבים בצורה חלקה בפרויקט האביב שלך (לדוגמה, אותה אבטחת קפיץ לעבודה עם הרשאות משתמש על אתר, שאני מקווה שגם נרגיש מתישהו).

למה אביב בג'אווה?

ובכן, חוץ מהעובדה שהוא אופנתי, מסוגנן וצעיר, אני יכול לומר מיד שברגע שתשלוט בזה אפילו קצת, תבין כמה עבודה אחרת אתה לא צריך לעשות עכשיו, וכמה אביב לוקח על עצמו. אתה יכול לכתוב כמה תריסר שורות של הגדרות, לכתוב כמה שיעורים - ותקבל פרויקט עובד. אבל ברגע שאתה מתחיל לחשוב כמה יש "מתחת למכסה המנוע", כמה עבודה מתבצעת, וכמה קוד היה צריך להיכתב אם אתה עושה את אותו פרויקט על servlets חשופים או על sockets ו-Java טהור - השיער שלך מזדקף :) יש אפילו ביטוי כזה, כמו ה"קסם" של האביב. זה כשאתה רואה שהכל עובד, אבל אתה מעריך בערך כמה צריך לקרות שם כדי שהכל יעבוד ואיך הכל עובד שם - אז נראה שכל זה קורה בזכות איזשהו קסם באמת)) יותר קל תקראו לכל זה קסם מאשר לנסות להסביר איך הכל קשור זה לזה. חיוך data_ web-mvc_ security_ רק היסודות.

DI/IoC

אם ניסית לקרוא משהו ב-Spring, אז הדבר הראשון שנתקלת בו היה כנראה האותיות האלה: DI/IoC . עכשיו אני מאוד ממליץ לך לקחת הפסקה מהמאמר הזה ולקרוא את המאמר הזה על Habré ! IoC (היפוך שליטה) - היפוך שליטה. כבר הזכרתי את זה באקראי כשכתבתי שבשימוש בספריה אתה בעצמך כותב בקוד שלך לאיזה שיטה לאיזה אובייקט לקרוא, ובמקרה של פריימים לרוב המסגרת תקרא לקוד שכתבת בצד ימין רֶגַע. כלומר, כאן אתה כבר לא שולט בתהליך ביצוע הקוד/תוכנית, אלא המסגרת עושה זאת עבורך. העברת לו את השליטה (היפוך שליטה). DI מובנת כ- Dependency Inversion (היפוך תלות, כלומר , ניסיונות לא ליצור קשרים קשים בין המודולים/המחלקות שלך, כאשר מחלקה אחת קשורה ישירות לאחרת), או Dependency Injection (הזרקת תלות, זה כאשר חפצי חתול אינם נמצאים נוצר על ידך בגדול ואז אתה מעביר אותם לשיטות שלך, ואביב יוצר לך אותם, ואתה פשוט אומר לו משהו כמו "אני רוצה להביא חתול לכאן" והוא מעביר לך את זה בשיטה שלך). לעתים קרובות יותר נפגוש את השני במאמרים נוספים.

שעועית והקשר

אחד ממושגי המפתח באביב הוא שעועית . בעצם, זה רק אובייקט של מעמד כלשהו. נניח עבור התוכנית שלנו אנחנו צריכים להשתמש ב-3 חפצים: חתול, כלב ותוכי. ויש לנו חבורה של כיתות עם חבורה של שיטות, שלפעמים אנחנו צריכים חתול לשיטה, וכלב לשיטה אחרת, ולפעמים יהיו לנו שיטות שבהן אנחנו צריכים חתול ותוכי (למשל, שיטה להאכלת חתול, hehe), ובשיטות מסוימות, יהיה צורך בכל שלושת החפצים. כן, אנחנו יכולים קודם כל ליצור את שלושת האובייקטים האלה בעיקרון, ואז להעביר אותם לשיעורים שלנו, ומתוך השיעורים לשיטות שאנחנו צריכים... וכך הלאה לאורך התוכנית. ואם גם אנחנו מדמיינים שמדי פעם אנחנו רוצים לשנות את רשימת הפרמטרים המקובלים לשיטות שלנו (טוב, החלטנו לשכתב משהו או להוסיף פונקציונליות) - אז נצטרך לבצע די הרבה עריכות בקוד אם נצטרך לשנות משהו. עכשיו, מה אם נדמיין שאין לנו 3, אלא 300 עצמים כאלה? אלטרנטיבה היא לאסוף את כל האובייקטים כאלו שלנו לרשימה אחת משותפת של אובייקטים ( List<Object> ) ולהעביר אותה לכל השיטות, ומתוך השיטות מקבלים אובייקט זה או אחר שאנו צריכים. אבל מה אם נדמיין שככל שהתוכנית מתקדמת, אובייקט כלשהו עשוי להתווסף לרשימה הזו, או (מה יותר גרוע) למחוק? ואז בכל השיטות שבהן אנו שואבים אובייקטים מהרשימה לפי האינדקס שלהם, הכל יכול להישבר. אז אנחנו מחליטים לאחסן לא רשימה, אלא מפה, שבה המפתח יהיה שם האובייקט שאנו צריכים, והערך יהיה האובייקט עצמו, ואז נוכל לקבל ממנו את האובייקטים שאנו צריכים פשוט לפי שמם. : get("parrot") ובתגובה קיבלנו תוכי חפץ או, למשל, המפתח הוא המחלקה של האובייקט, והערך הוא האובייקט עצמו, אז אנחנו כבר לא יכולים לציין את שם האובייקט, אלא פשוט את המחלקה של האובייקט שאנחנו צריכים, וזה גם נוח. או אפילו לכתוב סוג של עטיפה על המפה, שבה אתה יכול לעשות שיטות כך שבמקרים מסוימים תוכל לאחזר אובייקטים לפי שמם, ובמקרים אחרים לפי מחלקות. זה מה שאנו מקבלים מהקשר היישום האביבי . הקשר הוא קבוצה של שעועית (אובייקטים). אם נפנה להקשר, נוכל לקבל את השעועית (האובייקט) שאנו צריכים לפי שמה, למשל, או לפי הסוג שלה, או משהו אחר. בנוסף, אנחנו יכולים לבקש מאביב ללכת לחפש את השעועית שאנחנו צריכים בהקשר שלה ולהעביר אותה לשיטה שלנו. לדוגמה, אם הייתה לנו שיטה כזו:

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

כשאביב קרא לנו לשיטה זו, הוא העביר אליו את האובייקט של החתול שלנו מההקשר שלו. עכשיו אנחנו מחליטים שהשיטה שלנו, בנוסף לחתול, צריכה גם תוכי. שימוש באביב - שום דבר לא קל לנו יותר! אנחנו פשוט כותבים:

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

ואביב, כשזה יקרא לשיטה הזו שלנו, יבין שאנחנו צריכים להעביר כאן חתול ותוכי, ללכת להקשר שלו, לקבל את שני החפצים האלה ולהעביר אותם לשיטה שלנו. בהעברת מושכות התוכנית שלנו לאביב, העברנו אליו גם את האחריות ליצירת חפצים והעברתם לשיטות שלנו, שאותן הוא יקרא. נשאלת השאלה: איך ספרינג ידע אילו חפצים (פחים) ליצור?

שיטות תצורת יישום

ישנן שלוש דרכים עיקריות להגדיר יישום (כלומר, ספר ל-Spring אילו אובייקטים אנחנו צריכים לעבוד):

1. שימוש בקבצי xml/הגדרות;
2. שימוש בתצורות java;
3. תצורה אוטומטית.

מפתחי אביב מסדרים אותם בסדר עדיפות זה:

• השיטה העדיפה ביותר שיש לתת לה העדפה היא תצורה אוטומטית;
• אם שימוש בתצורה אוטומטית לא ניתן להגדיר כהלכה את כל השעועית האפשרית, השתמש בתצורת Java (יצירת אובייקטים באמצעות קוד Java);
• ובכן, הדרך הנמוכה ביותר היא הדרך המיושנת, באמצעות תצורות xml.

בנוסף, אביב מאפשרת לשלב בין שיטות אלו. לדוגמה, תן ל-Spring לעשות כל מה שניתן להגדיר באופן אוטומטי; היכן שאתה צריך לציין כמה פרמטרים מיוחדים, עשה זאת באמצעות הגדרות Java, ובנוסף, אתה יכול לחבר כמה הגדרות מדור קודם בפורמט xml. באופן כללי, כל זה יכול להיעשות בצורה גמישה למדי. אבל עדיין, אם הכל יכול להיעשות באמצעות הגדרות אוטומטיות, השתמש בזה. אני אשקול רק תצורה אוטומטית ותצורות Java; תצורות xml כבר נמצאות בשימוש כמעט בכל דוגמה של Spring באינטרנט, וברגע שתבינו איך תצורת Java עובדת, לא אמורה להיות בעיה "לקרוא" קובץ xml שעושה את אותו הדבר. תצורה אוטומטית משמשת כאשר האובייקטים שאנו צריכים לעבודה הם אובייקטים של מחלקות שכתבנו . אם יש צורך בהיגיון מסוים מאוד כדי ליצור אובייקט של המחלקה שלנו, או אם אין לנו הזדמנות לסמן מחלקה כלשהי עם ההערה שאנו צריכים, אשר ייקלט על ידי התצורה האוטומטית, ניתן לעשות זאת בתצורות Java . בחלק הבא , ניצור פרויקט מייבן, נחבר אליו כמה מודולי קפיצים מרכזיים וניצור את השעועית הראשונה שלנו.