http://www.asp.net/learn/data-access/tutorial-02-vb.aspx

רק שתבין כמה זה פלצני...

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

בסה"כ בנו קלאס עם פונקציות לטבלה ב DB וקראו לזה DAL.

אני מבין את הצורך בארגון ונוחות, אבל זה באמת ברור מאליו...

ברור שאתה יכול לרשום את ה-DAL ואת ה-BLL תחת אותה מחלקה , אבל זה יוצר סירבול ושיכפול קוד במקרים מסויימים ועוד הרבה דברים שעלולים להשתבש.
ד"א מה שרשמת בסוגריים כבר מספיק בשביל להשתמש בזה.

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

הדבר היחיד שלא דייקתי זה שלא אמרתי "שבסי'נס לוג'יק זה שכבה נפרדת" ממה שאתם מכנים DAL (סתם עוד אוסף של מחלקות שלך שמתעסקות בDATA, למשל DB).

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

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

2 הבעיות המרכזיות שנוצרות פה הן צמידות וחוסר אבסטרקטיות מה הכוונה ?

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

חוסר אבסטרקטיות :
נניח החלטתי מסיבות כאלו או אחרות לזנוח את ה DB ולעבור לתקשורת דרך WEB SERVICES , מה זה אומר ? שינוי מוחלט מבחינת ארכיטקטורה של המערכת אני פחות או יותר אצטרך לשכתב את כל המערכת שלי בשביל השינוי הזה.

אני אתייחס ל2 הנושאים הנוספים שאמרתי

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

אבטחה :
המתכנת הוא לא מבין גדול במסדי נתונים הוא מעביר את מה שהוא מקבל AS IS
נניח הוא מקבל INJECTION לתוך SQL הוא מעביר את זה ואנחנו אכלנו אותה כי שוב אין אף מנגנון שיבדוק את זה .

עכשיו כשמשתמים בשכבה לטיפול במידע כל הבעיות האלו נפתרות
הבעייה של הצמידות נפתרת, ה CLIENT כבר לא צריך להיות מתואם ל SERVER הוא רק צריך להכיר את השכבה ולדבר איתה ואת כל השינוים שבא לי לעשות אני עושה בשכבה עצמה.

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

מבחינת אבטחה ומקום לטעויות אני מוסיף עוד בדיקות נוספות ברמה של השכבה וככה אני EXTRA CAUTIOUS

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

היתה להם שכבה שהם קראו לה BL בפרויקט נפרד שהכילה את כל הקוד ב C# וגישה לשכבת נוספת שנקראת DAL בפרויקט נפרד שהעבירה שאילתות ל STORED PROCEDURES על ה SQL SERVER

בסופו של דבר זה היה קוד של כמה עמודי ASPX עם ה DLLים של שכבת ה DAL ושכבת ה BL.

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

דוגמאות מספר:
- תבניות-תכנון (Design-Patterns) - מקבץ פתרונות פשוטים לבעיות שכיחות
- תכנות-מונחה-אספקט (AOP) - מבט על כל מה שכבר יודעים, מנקודת מבט הפוכה
- פיתוח-מונחה-בדיקות (Test Driven Development) - לוודא שהכל עובד, תמיד
- מיפוי-אובייקטים-רלציוני - עוד באזז-וורד שאם יודעים לעבוד איתו יחסוך לכם ה-מ-ו-ן כאבי ראש
- יש עוד המון