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

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

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

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

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

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

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

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

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

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

• מודול לקוח — מכיל ממשק גרפי לכניסה ושליחה/קבלה של הודעות

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

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

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

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

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

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

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

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

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

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

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

2. הפרדת הנתונים אליהם אנו רוצים לשלוט על גישת המשתמש.

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

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

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

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

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