03-09-2007, 07:54
|
|
אדמין לשעבר
|
|
חבר מתאריך: 25.10.01
הודעות: 20,292
|
|
שאלה יפה :)
קןדם כל, בוא נבין מעט מה אומר מודל שלוש השכבות.
הרעיון פשוט - כשאנחנו מפתחים אפליקציה מורכבת, אנחנו רוצים לתמוך בהתרחבות עתידית. בתחזוקתיות של הקוד. בשביל זה, אנחנו מנסים להפריד בין רכיבים שיכולים להשתנות.
מה יכול להשתנות? הDB מולו אנחנו עובדים והתצוגות שאנחנו מציגים. אנחנו יוצאים מנקודת הנחה
שהלוגיקה שלנו לא משתנה, ואם כן - היא תמיד תגרור שינוי גם בתצוגות וגם בDB.
מה זה אומר?
זה אומר שאנחנו מייצרים בעצם את 3 השכבות האלו, עם חיבורים בינהן, והשאלה שלך בעצם - היא איך
לבצע את החיבורים?
אז קודם כל, לדרך ה"קלה" - התייעצות עם Design Patterns.
נתחיל משכבה שמכונה DAL (Data Access Layer) - השכבה הזאת תכיר את ה"אובייקטים העסקיים שלך" (להלן - שכבת הלוגיקה או השכבה העסקית BL). השכבה הזאת תדע לקחת את אותם אובייקטים
שיש לך במודל העסקי ותשמור אותם בDB, בלי שהמודל שלך בכלל מודע לצורה שבה זה נשמע.
מבחינת האפליקציה, המידע יכול להשמר בDB, בקובץ או בדו"ח. זה לא משנה, כי הדבר האחרון שהיא
מכירה זה את האובייקט העסקי שלך.
איך מבצעים את זה? ישנן כמה דרכים, מתוכן שתיים מקובלות:
1. OR/M - הרעיון הוא לקחת אובייקטים רגילים שיש לך באפליקציה, לייצר מיפוי שלהם לטבלאות ולשמור אותם בDB (ישנם כלים שעושים עבורך את העבודה כמו ה LINQ to SQL/Objecs החדש של MS או כלים כמו NHibernate).
2. DataSet - שכבת הBL שלך מייצרת DS, ואותו שכבת הDAL יודעת לשמור.
לשתי השיטות יש יתרונות וחסרונות.
השכבה השניה שנטפל בה - שכבת התצוגות. בשביל זה, ישנם שני מודלים נהוגים.
1. Mediator Pattern
2. Model-View-Controller (MVC Pattern).
היום נהוג יותר להשתמש באפשרות השניה (זו המתודולוגיה שComposite UI Application Block מממש.).
מה זה בעצם אומר?
יש לך תצוגה שחושפת Properties וDelegates. יש לך Controller שמכיר את התצוגה הזאת ומכיר את
המודל שלך (שזו בעצם שכבת הBL שלך) ומבצע את החיבור בין שתיהן. יודע לעדכן את התצוגה כשמשהו
במודל משתנה, ויודע לעדכן את המודל כשמשהו בתצוגה משתנה.
כך, ברגע שהתצוג משתנה - אתה משנה רק את הController.
מקווה שהצלחת להבין. אם אתה זקוק לעוד הבהרות, תרגיש חופשי לשאול.
_____________________________________
דורון
|