התיעצות

התיעצות

שלום לכולם יש לי טופס שכתוב ב-asp.net המכיל הרבה פרטים שהמשתמש מכניס. לאחר הכנסת הפרטים, המשתמש מועבר לדף אחר להמשך טיפול, וכן להזנת פרטי תשלום. שאלתי היא: איך לשמור את כל הפרטים שמולאו בטופס עד לאישור הסופי? האם בעוגיה..? האם יש דרך אחרת? תודה
 
הבהרות...

תודה
קראתי את המאמר, וקצת למדתי על session. המעבר שלי הוא בין 3 דפים, ואיסוף נתונים מהם. כלומר, מהדף הראשון מתקבלים נתונים על המשתמש, מהדף השני נתוני תמחור, ומהשלישי פרטי אשראי, והתהליך ממשיך עד לסליקה. ממה שהבנתי כדאי לי דוקא להשתמש ב-session, גם בגלל איסוף הנתונים, וגם בגלל שאין לי צורך להציג אותם, אלא לשמור אותם עד לאישור העסקה ואז להכניס אותם ל-DB. 1. האם הבנתי נכון? מה דעתכם? 2. למה דוקא ב- session סטטי? תודה, תודה, תודה
 
אין טוב כבעל ניסיון

וזה לא אני
,(אבל זה משהו שראיתי בספר של asp.net) אבל יש אפשרות לעשות מעין עגלת קניות זמנית\פרטים זמניים וזה פר לקוח(בDB זה יהיה קשר 1:1, אז במקום להעביר או לשמור את זה בזיכרון ,אז פשוט אם זה תקין ישר לשמור את זה בDB, ו אם לקוח יצא וחזר ולא עשה קנייה, תוכלי להציג לו את הפרטים בעגלת הקניות\הפרטים הזמניים כשהוא ירצה לחזור. כשהוא יעשה רכישה והכול יהיה תקין- אז צריך לעשות הזזה של נתונים מטבלת עגלת הקניות\פרטיים זמניים לאבלת ההזמנות הקבועות.
 
אז זהו...

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

לטבלה אחת גדולה זמנית או מקסימום 2 מקושרות וזמניות. רעיון אחר לגמרי, שעכשיו צץ לי. פשוט לשמור ישר לDB ולהוסיף שדה של סטטוס של מצב הרכישה\קנייה - מצבים אפשריים לשדה סטטוס:רכישה מאושרת, לא מאושר ,במשלוח, וכדומה. (לא מזמן מישהו פה-בפורום, רשם לי משהו בסיגנון, אולי אני אחפש את זה מאוחר יותר, והוא פירט יפה על מצבים אפשריים לסטטוס)
 
במקום "אתי יכולה לאחד" צריך להיות

את צריכה לאחד, (ואם קוראים לך אתי אז זה יצא בסדר
)
 
בא נחשוב יחד../images/Emo22.gif

נניח שהמידע נשמר ב-db עם שדה סטטוס. במקרה שהסטטוס=אושר המידע מופיע באתר. בכל מקרה אחר המידע נשמר סתם ב-db וצריך לדאוג למחוק אותו. אז צריך לכתוב SP ב-sqlServer שתמחק רשומות מיותרות, נניח אחרי יומיים, ושה-agent יריץ אותה כל לילה. איך זה נשמע?
חוץ מזה, תודה על הקדשת הזמן לתגובות.
 
זה תלוי מאוד בפרוייקט

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

adam222

New member
בעל ניסיון

לשמור ב-DB זה בעיה כי יכולים 15 גולשים או 150 גולשים בו זמנית לנסות לגשת. הפתרון שאני יישמתי, הינו 3 אובייקטים (class-ים לצורך הענין) כאשר ב-Class הראשון יש את הפרטים הבאים: ת.ז. שם פרטי ושם משפחה. class אחד לדוגמא:
public class firstPart { public string IdNumber; public string LastName; public firstPart() { IdNumber = string.empty; LastName = string.empty; } }​
בעת המעבר מהטופס הראשון לשני, אחרי ביצוע הוואלידציות על ההזנות של המשתמש, יצרתי אינסטנס חדש של ה-Class הזה, העברתי את הנתונים מהשדות ל-members של האינסטנס, והשמירה היא לתוך משתנה session בתור אובייקט שמכיל 3 אובייקטים של הרשמה ה-class שנשמר ב-session:
public class Registration { public firstPart partA = new firstPart(); public secendPart partB = new secendPart(); public thirdPart partC = new thirdPart(); public Registration(){} }​
ב-global.asax ב-OnSessionStart (או משהו כזה - פשוט הכל בע"פ) עבור כל session את יוצרת אינסטנס של Registration. ההשמה בעת מעבר למסך השני - לאחר מילוי האובייקט
session["Registration"].partA = localFisrtPart​
ש- localFisrtPart זהו האינסטנס הלוקאלי בדף של ה-Class FirstPart בהצלחה... <לא חשבתי שזו תהיה תשובה כה ארוכה...>
 
שאלה על הדרך

זה לא יותר מידי?כלומר שימוש מופרז בsession ובזיכרון.? מתי אתה מוחק את הsession, או שבעצם אתה מוחק רק הsession של הרישום,בסוף הרישום?
 
ועוד משהו ששמתי לב

אתה אומר לשמור בdb זה בעייה, כי יכולים 10 או 15 בו זמנית, אבל הרי גם בסוף הרישום כשהכול תקין יש שמירה בDB. או שפיספסתי משהו?
 

adam222

New member
.............

בשביל מי\מה אתה שומר את הזיכרון? אם לא עבור שימוש בו...? זה בטוח לא יותר מידי מכיון שהמידע הנשמר הוא טקסטואלי, זניח במשמעות הזיכרון. מחיקת ה-session מתבצעת ב-timeout או כשהמשתמש סוגר ת'דפדפן. ההשמה ל-DB היא רק פעם אחת ולא בכל שלב, ללא שימוש בטבלאות זמניות שזה העמסה פי כמה בזיכרון, כטבלה, קשרים ואינדקסים + JOB שהנ"ל רצתה להריץ בלילה לעדכן, למחוק וכיו"ב... שאלתך השניה: אני אומר שלשמור מידע זמני, כלומר משתמש1 סיים את שלב א, אני אשמור לטבלה זמנית את פרטי שלב א, לאחר 2 שניות, משתמש2 סיים את שלב א וגם הוא נשמר בטבלה זמנית... כמובן שניתן להפריד ביניהם באמצעות שמירת ערך ה-sosseionID, ואז עידכון וקריאה, סריקת טבלה זמנית, עדכון טבלה קבועה, מחיקת טבלה זמנית... לעומת זאת, אני שומר ל-DB פעם אחת בלבד וישירות לטבלה קבועה וזה רק אחרי שהכל מלא ומוכן. המשך הפעולות: אחרי הזנת פרטי התשלום (המסך האחרון) אני אגש לכל האובייקטים ב-Session ואזין אותם במכה אחת ל-DB. יעיל ונקי
ואח"כ אעיף את ה-session object בקשר למילוי חלקי 2 שלבים מתוך 3: זו בעיה גם בטבלה זמנית, בגלל שה-sessionID יישתנה גם הוא, אם כי ניתן גם לעשות את זה
 

adam222

New member
תיקון

בקשר למילוי חלקי 2 שלבים מתוך 3: את האובייקט Registration ניתן לסרייל (כמובן שצריך להוסיף לו תגיות xmlElemment) ולשמור את מצבו ה-XML-י ב-DB או בעוגיה ...
 

adam222

New member
זה תמיד

סטטוס חייב להיות גם ככה, הענין הוא בהרשמה... לא הפרטים לגבי המוצר, אלא לגבי ההרשמה! לצורך הענין נניח ויש לך 10 שלבי הרשמה (בהגזמה אך להמחשה) והמשתמש עבר 7 שלבים, קיבל טלפון מלקוח\נגמרה לו הסוללה ב-laptop וההרשמה נעצרה. אם שמרת ב-DB הזנת עבורו 7 שורות בטבלה זמנית וכל זה לא שווה כלום, כי הוא לא השלים את המסלול...
 
אתה צודק,אולם עוד נקודה חשובה

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