1-2-3 Tier!

[אוריגמיש]

1-2-3 Tier!

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

שכבה אחת
לא היתה באמת הגדרה לנושא, אבל מדובר במערכות Stand Alone לפני מספר עשורים,
פשוט מערכת שבה יש UI שבתוכו כתובה גם כל הלוגיקה, הכל כמקשה אחת.

שתי שכבות / Two Tier
הפרדה ל UI ול Business Layer,
מפסיקים לכתוב קוד ספגטי הכולל מימוש לוגיקה בצד ה UI ופניות ישירות לבסיס הנתונים,
אלא מממשים הפרדה בסיסית בין שכבת התצוגה לכל השאר,
כאשר ה UI זו השכבה הראשונה, וה Business Layer זו השכבה השנייה,
הכוללת בתוכה גם עבדה ישירה מול בסיס הנתונים, כאשר אמור להיות Facade ו API ברור בין שתי השכבות.

שלוש שכבות / Three Tier
בדומה לתפיסה הקודמת, אך עם פיצול של ה Bunisess Layer לשתי שכבות,
הראשונה שאחראית באמת על הלוגיקה העסקית, והשניה (DAL) האחראית על כל העבודה מול בסיס הנתונים,
כאשר כעת יש את שכבת התצוגה/UI שאחראית על חווית המשתמש,
השניה אחראית על הלוגיקה העסקית והשלישית אחראית על העבודה מול בסיס הנתונים,
כאשר כל שכבה חושפת את הפונקציונאליות הרלוונטית לשכבה שמעליה (בלבד), בשאיפה עם Coupling מינימלי ככל האפשר.

ריבוי שכבות / N-Tier / Multitier
בדומה לתפיסה הקודמת, כאשר כל שכבה יכולה להתפצל למספר שכבות משנה, לדוגמא:
שכבת ה UI תתפצל לשכבה שאחראית על ה UI והתצוגה נטו, ושכבת Controllers (או כל שם אחר, לא בהכרח רלוונטי ל MVC),
שאחראית על הלוגיקה הרלוונטית ל UI נטו (לדוגמא, אכיפת שדות חובה, לוגיקה המסייעת לחווית משתמש, ולידציות וכו')
דוגמא אחרת היא פיצול ה BL לשתי שכבות, שכבת Workflow האחראית על ניהול תהליך לוגי מסויים,
ושכבת BL האחריות על מימוש לוגיקה ספציפית (פונקציות אטומיות), כאשר ה WF אחראי לקרוא ל BL לפי הסדר ולנהל את התהליך הלוגי העסקי,
וכמובן גם את שכבר ה DAL אפשר לפרק לשכבה האחראית על עבודה נטו מול בסיס הנתונים (עם/ללא ORM),
ושכבה האחראית על קריאת לשכבת ה ORM וביצוע עיבוד בסיסי על התוצאות לפני החזרת התשובה ל BC וממנו כלפי מעלה.

מספר שאלות הבהרה:

1. האם בגדול התאור נכון, או שיש אי דיוקים מהותיים? אודה לכל הערה/הארה.

2. האם כאשר מדברים על שתי שכבות, מקובל להחיל את ה UI + לוגיקה כשכבה אחת, ואת בסיס הנתונים כשכבה השנייה,
או את ה UI כשכבה אחת, ולוגיקה + בסיס הנתונים כשכבה השנייה? (או שגם וגם מקובל, העיקר שיש סלט וספגטי

)

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

תודה.

 

[someboddy]

לפי מה שאני מבין

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

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

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

השיטה של 3 שכבות היא פשוט חלוקה ליותר מחשבים/תהליכים - לקוח, שרת ובסיס נתונים.

רק בMVC מתחילים לראות חלוקה עיצובית-לוגית - ומכאן גם המקור לריבוי השכבות. החלוקה לModel, View, Controller היא חלוקה לוגית, אבל לפעמים - לדוגמה באפליקציות רשת - רוצים גם לעשות חלוקה פיסית. מכיוון שהחלוקות לא חופפות, צריך לבצע חלוקות נוספות של חלק מהשכבות.

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

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

לBusiness Logic אין מחיצה פיסית באמצע, ולכן אפשר לשים את כולו בController, אבל לUI יש אותה בעיה כמו לשכבת הנתונים - הדפים אמורים להיות מוצגים על מחשב הלקוח, אבל יצירת קוד הHTML צריכה להיווצר בשרת. לכן גם כאן מחלקים - הView רץ בשרת ומכין את קו הHTML, ובצד הלקוח רץ דפדפן שמתרגם את הHTML לUI.

קיבלנו 5 שכבות:
Database
Model
View
Controller
Browser
מעבר לזה אני לא רואה שום סיבה להוסיף עוד שכבות, אבל ההיסטוריה של עולם המחשבים מלאה באנשים שלא ראו צורך בדברים ששנים לאחר מכן אנחנו לא מסוגלים לדמיין את עצמנו חיים בלעדיהם.