תכנון של N-Tier

[dc24]

תכנון של N-Tier

שלום. אשמח לשמוע עצות, תגובות ובכלל את דעתכם. אז ככה: אני בונה תוכנה, אמנם די קטנה, אך אני מנסה לבנות אותה במספר שכבות. כרגע אני עובד על גישה לבסיס נתונים. בינתיים אדבר רק על גישה לטבלה אחת - האחרות כמובן יהיו די זהות. על פי דוגמה שראיתי אני עשיתי מחלקה בשם TablenameInfo שיש בה משתנה פרטי עבור כל שדה בטבלה, ו-PROPERTY מתאים עבורו. מחלקה נוספת זו מחלקה בשם TablenameAccess, שממש ניגשת למסד הנתונים (השתמשתי ב-application block) ומכילה פונקציות שונות להכנסה/הוצאה וכו' לטבלה זו. השאלה שלי היא ככה : האם הערכים ששכבה זו יחזירו ל-Buisness Logic אמורים להיות מסוג TablenameInfo או שמא מסוג Dataset וה-BL (במקרה הצורך) ימיר אותם ל-TablenameInfo ? מה נראה לכם תכנון "נכון" יותר ? מה "נהוג" ? תודה רבה DC

 

[dc24]

אף אחד לא יודע ??

 

[ייוניי]

-->

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

 

[עידו פ]

שאלה קשה

שאני עדין לא מצאתי לגביה את התשובה (ואני כבר עובד על זה כמה חודשים). הגישה הרווחת : - אם מדובר במערכת אשר מציגה בכל פעם פרטים של ישות אחת - עדיף להעביר מבנה נתונים מוגדר (אותה מחלקת info). היתרונות - חוסכים את הנפח המפלצתי של dataset (להשתמש ב-dataset למקרה כזה זה כמו להרוג זבוב עם רובה פילים) החסרונות - יתכן שתצטרך לעבוד קצת קשה בשביל להכיל על מחלקות המידע שלך יכולות כגון bindable, serializable וכדומה (תקף לדוט נט, אבל מאחר וציינת שאתה משתמש ב-application blocks, אני מניח שמדובר בדוט נט). - אם מדובר במערכת אשר נוטה להציג גרידים, או ליתר דיוק - אוסף ישויות (רשימת ישויות) - עדיף להגדיר dataset (או ליותר דיוק - typed dataset) - היתרונות - מרוויחים את היכולות של dataset (יכולות Bind, sort, filter וכו') - החסרונות - אם רק מדובר בגרידים, לא בטוח שיש. אבל לרוב גריד גורר מתישהו הצגת פרט בודד, ואז מה עושים ?! אני כרגע לא מצאתי את הפתרון האולטימטיבי ואני במחשבה של אולי לשלב את שתי הגישות (אני יודע, זה ידרוש תחזוקה כפולה, אבל אני מקווה שאני אצליח לחיות עם זה). אם תרחיב קצת על האופי בה המערכת אמורה לעבוד, אולי נוכל לתת לך קצת יותר טיפים. רק בשביל להסב לך קצת בטחון - אני מכיר פרויקטים שונים שחלקם מבוצעים לגמרי באמצעות מבני נתונים (מחלקות או structs) וחלקם לגמרי באמצעות Typed DS ושני סוגי הפרויקטים מתפקדים כמו שצריך. ולגבי ה"נכון" ששאלת ושענו כאן - כשמפתחים בגישת השכבות (להבדיל מגישת OO "טהורה"), השימוש במחלקות להחזקת מידע (וחשיפתם באמצעות properties) הוא שימוש לגיטימי. דרך אגב, ישנם כלים מיוחדים שנקראים כלי ORM שמאפשרים בניית ישויות מידע על-סמך בסיס נתונים (יכול לחסוך לך את כל שלב בניית מחלקות לישויות)

 

[dc24]

תודה רבה...

 

[liortm]

לגבי Typed Ds

אפשר גם לירוש ממנו להוסיף לו מאפיינים רלוונטיים וכך לייצר class שנותן מענה כולל יותר.