none
OOP וחלוקה לשכבות, RRS feed

  • שאלה

  • שלום אני עובדת בC#, fw4.0 .net

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

    יש לי תוכנה שבה חילקתי ל3 שכבות: BL,DL, GUI

    וכן בתוכנה עשיתי הורשה של קלאסים שבשכבות BL וDL  יש לי קלאס אבא ויש כמה קלאסים שהם יורשים. בהתאמה ב2 השכבות.

    כך שBL  מכיל קלאסים שעושים את הלוגיקה העסקית לדוג': BLBase1, BLDerive1,BLDerive2

    וDL מכיל קלאסים שמתקשרים עם הDB (פרוצדורות פונקציות) לדוג': DLBase1, DLDerive1,DLDerive2

    BLBase1 מכיל אוביקט   DLBase1(protected) שמתקשר עבורו עם הDB, הוא מקבל ייחוס בהתאמה אם הוא אבא או בן.

    השימוש בהם התחלק.

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

    זה המושלם והטוב, גם חלוקה לשכבות ושם הורשה.

    הבעיה היא במסכים שאין לי הרבה לוגיקה שמצריכה יצירת אוביקט של BLBase1 או כל אוביקט שהוא מסוג BL, כל מה שאני צריכה זה את התקשורת לDB .

    חשבתי על 3 פתרונות למסכים אלו:

    1. ליצור בהם אוביקט מסוג DLBase1, שהוא יעשה את התקשורת לDB.

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

    1. ליצור בהם אוביקט מסוג BLBase1 שהוא יתקשר לDB  כמו במסכים עם לוגיקה.

    הבעיה בשיטה הזו שבעצם מה שיש לי במסכי הBL זה רק ההגדרה של הפונקציות ולא דבר מעבר להם

    Public virtual int GetInt(int bla){return DLBase.GetInt(bla);}

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

    הרבה מלל רק בשביל הגדרה. זה מסרבל לעקוב אחרי כזה קוד ואולי סתם מיותר.

    1. בתוך BLBase1 יש אוביקט של DLBase1, אם אני הופכת אותו לpublic,(כעת הוא protected) אני אאפשר למסכים שלי ליצור מופע של BL  ולהפעיל מתוכו את הפונקציות שמתקשרות עם הDB.

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

    אז מה הכי נכון ונוח לעשות?

    • שינה את הסוג Eran Sharvit יום שני 03 נובמבר 2014 16:33
    • שינה את הסוג Eran Sharvit יום שלישי 04 נובמבר 2014 11:42
    יום ראשון 02 נובמבר 2014 12:49

תשובות

  • כן, הצלחת בגדול.. הרבה יותר קריא וברור.

    כפי שאת בוודאי יודעת, לא תמיד יש "נכון" או "לא נכון". יש המון דרכים לעשות דברים והמון שיטות.

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

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

    לכן במקרה הספציפי שלך - הגישה לשכבת ה- DL צריכה להיות משכבת ה-BL בלבד. אין לאפשר גישה ישירות מה- GUI ל- DL אלא ליישויות העסקיות בלבד.


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


    • נערך על-ידי Eran Sharvit יום שלישי 04 נובמבר 2014 11:39
    • הוצע כתשובה על-ידי pituachMVP, Moderator יום שישי 07 נובמבר 2014 10:19
    • סומן כתשובה על-ידי יפהפיה נרדמת יום ראשון 09 נובמבר 2014 06:18
    יום שלישי 04 נובמבר 2014 11:35
  • >> נראה לי יש לך חוסר הבנה של המערכת שלי.כשאתה מתכוון ל DL, אתה מתכוון לקלאס הDATA LAYER שמכיל את הפתיחה והסגירה של הDB ואת הפונקציות ששולפות נתונים או מפעילות פרדצורות בDB.

    את צודקת, בגלל זה התחלתי קודם כל עם ההגדרות של השכבות :-)

    "אני מניח שאת מתכוונת לשכבות UI, BL, ו DB (שנקרה DL גם כן Data layer).
    User Interface, Business Logic, Databas"

    חשוב מאוד בתחילת דיון קודם לוודא שאנחנו מדברים באותה שפה :-)

    >> כשאני כתבתי DL התכוונתי לשכבה (תיקיה) שכוללת גם את הקלאס הנ"ל אבל גם אוביקטים ספציפים שהם עושים את התקשורת לקלאס הזה.

    מחלקות הקשורות למחלקות הנתונים שלנו, כגם אם אינן ישירות מקבילות לטבלחאות במסד הנתונים צריכות להיות תחת ה DL. למשל אם יש לנו טבלה שכוללת 3 טורים ואנחנו יוצרים מחלקה שכוללת את אותו אלמנט אבל רק עם 2 טורים או אלמנט שמוגדר מצירוף של טבלאות, אז מקומה של המחלקה יכול להיות ב DL (או ב BL). זה חלק מהלוגיקה של המסד נתונים

    אבל

    >> למשל כפתור בGUI שצריך להחזיר מספר מהDB מפעיל פונקציה של אוביקט מהDL, (נניח DLDog)
    לפונקציה הזו קוראים GetInt והיא בתוכה כותבת את משפט הSELECT הפשוט בתוך string,
    ומפעילה פונקציה של DATA LAYER שנקראת GetData (שהיא פונקציה גנרית המקבלת SqlString ומחזירה ערך Int
    מההDB)

    המתודה עצמה שעובדת מול מסד הנתונים בהחלט ניתן למקם ב DL. הגישה למתודה הזו אמור להיות דרך ה BL ולא ישירות מה UI.

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

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

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


    signature   Ronen Ariely
     [Personal Site]    [Blog]    [Facebook]

    יום רביעי 05 נובמבר 2014 07:37
    מנחה דיון

כל התגובות

  • סיבכתי ממש ולכן אף אחד לא מגיב?

    האמת אני יודעת שהאופציה השניה היא בטח תהיה המומלצת, כי היא מכסה הכל.

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

    יום שני 03 נובמבר 2014 13:11
  • קצת :-)

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

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

    בינתיים הייתי עסוק בפרסום המאמר:
    Representing List of Values Using a Single Value

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

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


    signature   Ronen Ariely
     [Personal Site]    [Blog]    [Facebook]

    יום שני 03 נובמבר 2014 15:32
    מנחה דיון
  • היפיפיה הנרדמת, אני מציע לך לנסות לנסח את השאלה יותר בקצרה ובבהירות, ואם אפשר לצרף קטע קוד. זה יקל את האנשים לענות.

    עד אז, אני משנה את האשכול לדיון. במידה ותערכי את השאלה שוב, אני אשנה מחדש את האשכול.

    תודה.


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

    יום שני 03 נובמבר 2014 16:33
  • ערן, האמת שאני מאריכה ומפרטת בגלל שכבר למדתי בשאלות אחרות שלי שניסתי לתמצת ואז בא רונן ואמר אי אפשר לשאול ככה את חייבת להציג לנו את כל מפת השאלה.

    רונן, אתה נשמע עסוק סופר! מה יש עוד שבועיים? אני יודעת על שבוע אורקל. זה?

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

    שאלה קצרצרה:

    המערכת שלי בנויה על 3 שכבות BL,DL,GUI,

    וכן בכל שכבה יש קלאס אבא וקלאסים יורשים שמייצגים לי את אוביקטים שלי.

    הנכון ביותר ש gui יתקשר רק עם bl והוא יתקשר רק עם dl. נכון?

    וזה מה שאני אכן עושה במסכים עם לוגיקה ארוכה.

    אבל יש לי מסכים שאין לי צורך ביצירת אוביקט bl ונטו כל השימוש שלי בו יהיה לקרוא לפונקציה בשם דומה שנמצאת בשכבת הdl.

    לכן ויתרתי במסכים אלו על יצירת אוביקט של bl, וישר יצרתי אוביקט של dl.

    אין הרבה סיכוי שבעתיד יתפתח צורך לשימוש נרחב של bl.

    (ועוד הוספה: בגלל שגם כל שכבה מכילה אב ויורשים אז כל "רק" יצירת פונקציה שקוראת לdl מצריכה יצירה שלה בבערך 4 קלאסים.)

    עד כמה מה שעשיתי חמור לא נכון או שדוקא זה הגיוני ומקובל?

    ערן, הצלחתי?


    יום שלישי 04 נובמבר 2014 11:21
  • כן, הצלחת בגדול.. הרבה יותר קריא וברור.

    כפי שאת בוודאי יודעת, לא תמיד יש "נכון" או "לא נכון". יש המון דרכים לעשות דברים והמון שיטות.

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

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

    לכן במקרה הספציפי שלך - הגישה לשכבת ה- DL צריכה להיות משכבת ה-BL בלבד. אין לאפשר גישה ישירות מה- GUI ל- DL אלא ליישויות העסקיות בלבד.


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


    • נערך על-ידי Eran Sharvit יום שלישי 04 נובמבר 2014 11:39
    • הוצע כתשובה על-ידי pituachMVP, Moderator יום שישי 07 נובמבר 2014 10:19
    • סומן כתשובה על-ידי יפהפיה נרדמת יום ראשון 09 נובמבר 2014 06:18
    יום שלישי 04 נובמבר 2014 11:35
  • >> רונן, אתה נשמע עסוק סופר! מה יש עוד שבועיים? אני יודעת על שבוע אורקל. זה?

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

    >> המערכת שלי בנויה על 3 שכבות BL,DL,GUI,

    אני מניח שאת מתכוונת לשכבות UI, BL, ו DB (שנקרה DL גם כן Data layer).
    User Interface, Business Logic, Databas

    מאוד מומלץ להיכנס ולקרוא את הספר הבא, הוא מכסה הכל בנושא ארכיטקטורת השכבות בפיתוח:
    http://msdn.microsoft.com/en-us/library/ff650706.aspx

    >> רונן ואמר אי אפשר לשאול ככה את חייבת להציג לנו את כל מפת השאלה.

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

    >> הנכון ביותר ש gui יתקשר רק עם bl והוא יתקשר רק עם dl. נכון?

    תיאורטית בהחלט נכון.

    >> אבל יש לי מסכים שאין לי צורך ביצירת אוביקט bl ונטו כל השימוש שלי בו יהיה לקרוא לפונקציה בשם דומה שנמצאת בשכבת הdl.. 

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

    >> אין הרבה סיכוי שבעתיד יתפתח

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

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

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

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

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

    >> עד כמה מה שעשיתי חמור לא נכון או שדוקא זה הגיוני ומקובל?

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

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

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

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


    signature   Ronen Ariely
     [Personal Site]    [Blog]    [Facebook]


    יום שלישי 04 נובמבר 2014 17:17
    מנחה דיון
  • רונן סליחה סליחה סליחה. בהצלחה ענקית בהרצאה.

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

    בקשר לתשובה המושקעת כרגיל שלך:

    נראה לי יש לך חוסר הבנה של המערכת שלי.

    כשאתה מתכוון ל DL, אתה מתכוון לקלאס הDATA LAYER שמכיל את הפתיחה והסגירה של הDB ואת הפונקציות ששולפות נתונים או מפעילות פרדצורות בDB.
    ולכן נתת לי על הראש מה אני שמה שם לוגיקה.
    כשאני כתבתי DL התכוונתי לשכבה (תיקיה) שכוללת גם את הקלאס הנ"ל אבל גם אוביקטים ספציפים שהם עושים את התקשורת לקלאס הזה.
    למשל כפתור בGUI שצריך להחזיר מספר מהDB מפעיל פונקציה של אוביקט מהDL, (נניח DLDog)
    לפונקציה הזו קוראים GetInt והיא בתוכה כותבת את משפט הSELECT הפשוט בתוך string,
    ומפעילה פונקציה של DATA LAYER שנקראת GetData (שהיא פונקציה גנרית המקבלת SqlString ומחזירה ערך Int
    מההDB)

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

     

    יום רביעי 05 נובמבר 2014 06:22
  • >> נראה לי יש לך חוסר הבנה של המערכת שלי.כשאתה מתכוון ל DL, אתה מתכוון לקלאס הDATA LAYER שמכיל את הפתיחה והסגירה של הDB ואת הפונקציות ששולפות נתונים או מפעילות פרדצורות בDB.

    את צודקת, בגלל זה התחלתי קודם כל עם ההגדרות של השכבות :-)

    "אני מניח שאת מתכוונת לשכבות UI, BL, ו DB (שנקרה DL גם כן Data layer).
    User Interface, Business Logic, Databas"

    חשוב מאוד בתחילת דיון קודם לוודא שאנחנו מדברים באותה שפה :-)

    >> כשאני כתבתי DL התכוונתי לשכבה (תיקיה) שכוללת גם את הקלאס הנ"ל אבל גם אוביקטים ספציפים שהם עושים את התקשורת לקלאס הזה.

    מחלקות הקשורות למחלקות הנתונים שלנו, כגם אם אינן ישירות מקבילות לטבלחאות במסד הנתונים צריכות להיות תחת ה DL. למשל אם יש לנו טבלה שכוללת 3 טורים ואנחנו יוצרים מחלקה שכוללת את אותו אלמנט אבל רק עם 2 טורים או אלמנט שמוגדר מצירוף של טבלאות, אז מקומה של המחלקה יכול להיות ב DL (או ב BL). זה חלק מהלוגיקה של המסד נתונים

    אבל

    >> למשל כפתור בGUI שצריך להחזיר מספר מהDB מפעיל פונקציה של אוביקט מהDL, (נניח DLDog)
    לפונקציה הזו קוראים GetInt והיא בתוכה כותבת את משפט הSELECT הפשוט בתוך string,
    ומפעילה פונקציה של DATA LAYER שנקראת GetData (שהיא פונקציה גנרית המקבלת SqlString ומחזירה ערך Int
    מההDB)

    המתודה עצמה שעובדת מול מסד הנתונים בהחלט ניתן למקם ב DL. הגישה למתודה הזו אמור להיות דרך ה BL ולא ישירות מה UI.

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

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

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


    signature   Ronen Ariely
     [Personal Site]    [Blog]    [Facebook]

    יום רביעי 05 נובמבר 2014 07:37
    מנחה דיון