חלק 2. בואו נדבר קצת על ארכיטקטורת תוכנה

חומר זה הוא חלק מסדרת " מבוא לפיתוח ארגוני ". החלק הראשון על הרשת נמצא כאן . ארכיטקטורת תוכנה היא המבנה שעל בסיסו נוצרת אפליקציה והמודולים והרכיבים של התוכנית כולה מקיימים אינטראקציה. מתכנתים מנסים ליצור ארכיטקטורה טובה במשך זמן רב מאוד, ולכן אין זה מפתיע שאנו מכירים כיום הרבה דפוסים ארכיטקטוניים. אתה צריך להבין אותם: כשאתה כותב יישום אינטרנט, בעיית הארכיטקטורה הופכת לאקוטית, כי יש בה יותר רכיבים ומודולים מאשר ביישום רגיל. דפוס ארכיטקטוני הוא דרך כבר מחושבת לפתור בעיה כלשהי בתכנון תוכנה. סביר להניח שכבר נתקלתם בדפוסי עיצוב כמו Factory Method, Abstract Factory, Builder, Prototype, Singleton, ואולי אחרים. הם משמשים פשוט לכתוב קוד, ליצור כיתות ולתכנן את אופן האינטראקציה שלהם. נעשה שימוש בדפוסים אדריכליים ברמת הפשטה גבוהה יותר - בעת תכנון האינטראקציה של משתמש האפליקציה עם השרת, הנתונים ושאר מרכיבי הפרויקט. בואו נסתכל במהירות על כמה תבניות וכיצד להשתמש בהן.

ארכיטקטורת שרת-לקוח

מהשם מתקבל הרושם שהכל עם הנושא הזה פשוט וברור. אבל בואו נבהיר כמה נקודות כדי שכשתתחיל ללמוד את האביב המותנה, תבין בדיוק על מה אנחנו מדברים. נניח שכתבת צ'אט, ואתה והחבר שלך מתחילים להשתמש בו. אופציה פשוטה אפשרית כאן - אתם שולחים הודעה אחד לשני ישירות דרך האינטרנט באמצעות כתובות IP שאתם מכירים: בהתחלה אולי נראה שהכל עובד כשורה, עד שיופיע חבר אחר שלכם עם השאלה: "למה לא אתה לא מוסיף אותי לצ'אט שלך?" וכאשר אתה מחליט להוסיף חבר משותף לצ'אט, אתה מתמודד עם בעיה ארכיטקטונית: כל משתמש בצ'אט צריך לעדכן מידע על מספר המשתמשים, להוסיף את כתובת ה-IP של המשתמש החדש. ובעת שליחת הודעה יש להעבירה לכל המשתתפים. אלו הבעיות הברורות ביותר שיצוצו. הרבה יותר בעיות יוסתרו בקוד עצמו. כדי להימנע מהם, עליך להשתמש בשרת שיאחסן את כל המידע על המשתמשים ויידע את הכתובות שלהם. ההודעה תצטרך להישלח רק לשרת. והוא, בתורו, ישלח את ההודעה לכל הנמענים. כאשר תחליט להוסיף צד שרת לצ'אט שלך, תתחיל לבנות ארכיטקטורת שרת-לקוח.

רכיבי ארכיטקטורת שרת-לקוח

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

1. לקוח - מהשם מתברר שמדובר במשתמש בשירות (אפליקציית אינטרנט) שיוצר קשר עם השרת כדי לקבל מידע כלשהו.

2. שרת הוא המקום בו נמצא יישום האינטרנט שלך או חלק השרת שלו. הוא הבעלים של המידע הדרוש על משתמשים או יכול לבקש אותו. כמו כן, כאשר לקוח יוצר קשר, השרת מחזיר לו את המידע המבוקש.

3. הרשת פשוטה: היא מבטיחה חילופי מידע בין הלקוח לשרת.

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

• לקוח - מכיל ממשק גרפי להרשאה, שליחת/קבלת הודעות;

• server-side - אפליקציית אינטרנט שמתארחת בשרת ומקבלת הודעות ממשתמשים, מעבדת אותן ואז שולחת אותן לנמענים.

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

ארכיטקטורה תלת-שכבתית

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

1. שכבת הלקוח היא ממשק המשתמש. זה יכול להיות דפדפן אינטרנט שאליו נשלחים דפי HTML, או יישום GUI שנכתב באמצעות JavaFX. העיקר שבעזרתו המשתמש יכול לשלוח בקשות לשרת ולעבד את התגובות שלו.

2. שכבת הלוגיקה היא השרת שבו מעובדות בקשות/תגובות. לעתים קרובות היא נקראת גם שכבת השרת. כל הפעולות הלוגיות מתרחשות גם כאן: חישובים מתמטיים, פעולות נתונים, שיחות לשירותים אחרים או אחסון נתונים.

3. שכבת הנתונים היא שרת מסד הנתונים: השרת שלנו ניגש אליו. שכבה זו מאחסנת את כל המידע הדרוש שהאפליקציה משתמשת בו במהלך הפעולה.

לפיכך, השרת שלנו לוקח על עצמו את כל ההתחייבויות לגישה לנתונים, מבלי לאפשר למשתמש לגשת אליהם ישירות.

היתרונות של ארכיטקטורה תלת-שכבתית

באמצעות ארכיטקטורה כזו, אנו מקבלים יתרונות רבים, כולל:

1. היכולת לבנות הגנה מפני הזרקות SQL היא התקפה על השרת בו מועבר קוד SQL, וכאשר קוד זה מבוצע, התוקף יכול להשפיע על מסד הנתונים שלנו.

2. תיחום נתונים שאליהם אנו רוצים להסדיר את גישת המשתמש.

3. יכולת לשנות נתונים לפני שליחתם ללקוח.

4. מדרגיות - היכולת להרחיב את האפליקציה שלנו למספר שרתים שישתמשו באותו מסד נתונים.

5. פחות דרישות לאיכות החיבור של המשתמש. כשיוצרים תגובה בשרת, אנחנו לוקחים הרבה מידע ושונה ממסד הנתונים, מפרמטים אותו, ומשאירים רק את מה שהמשתמש צריך. כך אנו מצמצמים את כמות המידע שאנו שולחים כתגובה ללקוח.

באיזו תדירות כדאי להשתמש בדפוסים אדריכליים?

אם אתה מכיר, למשל, את תבנית העיצוב של שיטת המפעל , בטח תהיתם מתי להשתמש בו. לפעמים קשה להחליט מה לעשות: ליצור אובייקט באמצעות האופרטור החדש או בשיטת מפעל. אבל עם הזמן, ההבנה מגיעה. עם דפוסים אדריכליים, הדברים קצת שונים. מסגרות ארגוניות מיועדות למתכנת להשתמש בהן ליצירת פרויקט המבוסס על דפוס מקובל כלשהו. לכן, לפני לימוד ה-Spring Framework, אתה בהחלט צריך להבין מה הן ארכיטקטורת שרת-לקוח, ארכיטקטורת שלוש שכבות וארכיטקטורת MVC. אל דאגה: על ארכיטקטורת MVC נדבר מאוחר יותר. חלק 1. מה שאתה צריך לדעת לפני לימוד Spring ו-JavaEE חלק 3. פרוטוקולי HTTP/HTTPS חלק 4. יסודות Maven חלק 5. Servlets. כתיבת אפליקציית אינטרנט פשוטה חלק 6. מיכלי Servlet חלק 7. היכרות עם תבנית MVC (Model-View-Controller) חלק 8. כתיבת אפליקציית קפיץ-אתחול קטנה