מתנסה ב pattern...

[כלמנסע]

מתנסה ב pattern...

שלום לכם, אני חדש בכל העניין של patterns, ואולי השאלה שלי עוסקת ב OO בכלל. בקיצור: אני בונה אתר ב asp.net. יש דפים מסויימים למערכת הניהול. מתוכם יש הרבה דפים שמבצעים הוספת נתונים ל DB. אני מזהה תבנית מסויימת שמתקיימת בכל הדפים הנ"ל: 1. קלוט נתונים 2. ודא קלט. אם קלט לא תקין - תן הודעה וצא. 3. הוסף נתונים ל DB. אם משהו לא תקין - תן הודעה (+ לוג פנימי) וצא 4. הצג הודעת סיום מה שחשבתי זה שאולי זה יהיה יותר אלגנטי "לעשות עם זה משהו", אבל אני לא יודע מאיפה להתחיל. תודה מראש!

 

[עידו פ]

מאמר שכדאי לקרוא

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/diforwc.asp אומנם קצת ישן אבל עדין אקטואלי. במקרה שלך, אני ממליץ גם שתתמקד בפרק השני, על-מנת למצוא את ה-pattern שיכול להתאים לך. האם יש לך התחלה של רעיון לגבי האריכטקטורה הבסיסית של המערכת ?

 

[כלמנסע]

מנסה להתניע...

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

BaseInsert CTOR: BaseInsert (BaseInput baseInput, BasePage basePage) public, yet abstract methods: Execute()​

כאשר ה interfaces האחרים הם:

BaseInput BasePage public, yet abstract methods: DisplayErrorMessage (string suggestedMessage) DisplaySuccessMessage (string suggestedMessage)​

האם אני בכיוון?

 

[עידו פ]

אני אחזור שוב על שאלתי

האם חשבת כבר על הארכיט' של המערכת ? האם הדפים יפנו ישר ל-DB באמצעות ADO.NET ? או שאולי באמצעות רכיב שמפשט את הגישה ל-DB, כגון ה-DAAB של מיקרוסופט ? או שאולי אתה רוצה להוסיף שכבת אבסטרקציה שאחראית על הגישה ל-DB ? האם חשבת איך יראו מבני המידע שלך ? האם תממש אותם באמצעות מחלקות שתכתוב בעצמך ? או שאולי חשבת להשתמש ב-DS ? אולי ב-TDS ? איפה הולכת לשבת הלוגיקה של ישויות המידע ? האם רק במסך ? האם תשב במחלקה של ישות המידע ? האם שילוב של השניים ? ואם האחרון, איך השילוב יבוצע ? יש כמה דברים שכדאי לתת את הדעת עליהם לפני שהולכים ישר למסכים וקובעים להם DP, כי החלטות אלה ישפיעו בסופו של דבר על ההחלטה של כיצד ייושם המסך.

 

[כלמנסע]

תשובות

אני משתמש בכלי שנקרא ORM.net. הוא ממפה לי את ה DB לישויות (פחות או יותר). אני מתכוון לעבוד רק מול MSSQL בפרויקט הזה, כך שהכלי מתאים (כי זה כלי שעובד רק מול MSSQL). בגלל זה גם אין לי צורך ב DAAB. הכלי מייצר לי ישויות של Collections ויחידים (למשל Employee ו EmployeeCollection). הלוגיקה (הלא מסובכת מדי) תשב ב Code Behind. אולי לוגיקה מורכבת תשב ברכיב נפרד. תודה על תשומת הלב ועל הזמן. אני מקווה שהפרטים שרשמתי כאן נותנים תמונה טובה יותר על המערכת.

 

[עידו פ]

-->

אם כך כל מה שאתה צריך, כפי שהגדרת, זה: 1. לטעון את ישוית המידע 2. להציג אותן 3. לטפל בעדכונים של הישויות אם כך, קונספט ה-MCV יכול לשמש אותך בצורה שתהיה מאוד נוחה לך לממש אותו: 1. המודל כבר קיים לך (ישויות המידע שנבנו ע"י כלי ה-ORM) 2. הקונטרולר, במקרה שלך, יכול להיות ה-codebehind של דפי ה-ASPX 3. כפי שהצעת, תוכל לבנות interface שכל דף יממש ובכך יחייב כל דף לבצע 2 פעולות: א. טעינה של הדף (טעינת המידע לתוך ישויות המידע והצגת הישויות ב-ASPX) ב. שמירה (העברת הנונים מהדף בחזרה לישויות המידע וביצוע persistance) כמובן שה-Interface הזה הוא רק הבסיס כי כל דף יצטרך גם לטפל בכל האירועים השונים שקורים בדף, ומאחר ואתה עובד עם אובייקטים שעלולים להיות גדולים וכן מאחר וסביבת ASP.NET אינה שומרת נתונים בין postback ל-postback (למעט viewstate וכדומה), כדאי שתחשוב על איך הולך להיות מנגנון ה-caching שלך (אם בכלל תכננת לעשות אחד).

 

[liorsh]

אוקיי

אני לא יודע אם יש משהו מוכן. אני בטוח שיש כל מיני קטעי קוד שיכולים לעזור לך. אתה יכול לחפש ב CodeProject וכו'. אבל אתה שואל על התכנון. באופן כללי, כשמתכננים מערכת OO יש כלל אחד שמאוד עוזר לי לחשוב ולפשט את העניינים: Encapsulate the concept that varies. יעני, תעטוף את מה שמשתנה ככה שכלפי חוץ זה יראה אותו דבר. ז"א, שבדוגמה שלך, מה שמשתנה זה המידע שנכנס ויוצא (הודעות וכו') וכמו כן סוג האימות שאתה צריך לעשות. אז אתה יכול לכתוב קטע קוד יחיד שבודק, מבצע הוראות ומבצע אימות וכו'. מה שמשתנה לך זה המידע עצמו והאלגוריתם לאימות וכו' (כבר עולה פה דפוס תכן בשם command). כלל האצבע הזה הוא לא המצאה שלי, אם תקרא את הספר של ה GOF, אתה תראה שהכלל הזה עובר כחוט השני בכל הדפוסים. בפרק השני של הספר, הם מתארים איך הם מנסחים את הדפוסים ושם הם מעלים את הכלל המרכזי הזה. לצורך הענין, זאת כנראה השורה הכי חשובה ומעניינת בספר. מקווה שעזרתי, ליאור

 

[ייוניי]

נסיון לפשט

נתחיל כמובן בממשקים:

public interface DataEntryPage { void retrieveData(); void validateData(MessageSender sendErrorsWithThisSender); void commitDataToDB(MessageSender sendErrorsWithThisSender, Logger log); void showDoneMessage(MessageSender sender); } public interface MessageSender { void sendMessageAndQuit(string messageText, bool thisIsAnErrorMessage); } public interface Logger { void writeToLog(string text); }​

לגבי היישום הייתי בונה דף עם panel ריק, אזור להודעות וכפתור "אישור" - בטעינה יוצר אובייקט שמיישם DataEntryPage ושולח אליו את ה panel (הוא כבר יציג שם user control עם הפקדים המתאימים או משהו כזה), ואז קורא ל retrieveData. בארוע לחיצה על כפתור אישור קורא ל validateData ושולח אובייקט המיישם MessageSender (וכמובן שם את ההודעה במקום המתאים במסך + בצבע בולט אם מדובר בהודעת שגיאה). אח"כ בודקים אם אין שגיאות אפשר לקרוא ל commitDataToDB ואם גם זה עובר חלק קוראים ל showDoneMessage. כמובן שזה לא הסוף כי כדאי ליצור את אובייקט ה DataEntryPage באופן דינמי (אולי ע"פ פרמטר מה Request...) כך שלמעשה יהיה לך דף ASPX אחד עבור כל המסכים שמאופיינים על ידי ההתנהגות הזו. אבל במינימום יצרת הפרדה נעימה בין אובייקט ה page ללוגיקה העסקית שלך ואתה חוסך כתיבה כפולה של דפים. בנוסף, התחלת תגובת שרשרת שתוביל לשיפור העיצוב של התוכנה שלך (לאט, לאט ובזהירות).

 

[כלמנסע]

תודה לכולם

כמו שאומרים: אני מודה מודה מודה לכל מי שהסביר את העניין. אני אשתדל לכתוב בהמשך במה בחרתי (ולמה).