התייעצות לגבי עיצוב של אפליקציה

זורום

New member
התייעצות לגבי עיצוב של אפליקציה

שלום, כתבתי את ההודעה הבאה בפורום שפות תכנות, אולם אני מאמין שזהו פורום שיותר מתאים. אשמח להתייחסותכם. אני מפתח אפליקציה שתנהל רשימה של סוגי ישויות, שלהם יש מאפיינים שונים. לכל מאפיין יכול להיות פירוק הירארכי לתת מאפיינים ולתת-תת-מאפיינים וכו'. מטבע הדברים, אני חושב על ניהול כקבצי קונפיגורציה ב-XML. כל אלמנט יכיל מאפיינים (שם הרמה, פרטים תומכים). הרמה התחתונה תהיה ערך הנתון הנדרש על מאפייניו. מדובר למעשה בסכמה רקורסיבית די פשוטה שמספקת מבנה גמיש להגדרת הירארכיה כלשהי, ללא כל חשיבות לערכי הרמות עצמן. דוגמה לכך היא רשומת עובד. יש לו מאפיין של יצירת קשר. ליצירת קשר יש תת מאפיין של כתובת. לכתובת יש נתונים של רחוב, עיר, מיקוד וכו'. מעבר לכך, אני נדרש לתת למשתמש להזין ישויות שונות. אני צריך לספק לו VIEWS שונים של סוג היישות עבור הזנת נתונים (כל פעם שדות אחרים במהלך הזנת הערכים – למשל, בדפי הזנה עוקבים) והוא מזין ערכים בנתונים. יכול להיות בהחלט מצב בו המשתמש מזין נתון אחד (שמשתייך לנתיב הירארכי מסוים בסוג היישות) ובדף הבא הוא נדרש להזין נתון נוסף שמשתייך לאותו נתיב הירארכי. ישנה אף דרישה לנהל VIEWS שונים למשתמשים שונים. כדוגמה – משתמש אחד יצטרך בדף הראשון להזין את העיר, ובדף שני להזין את הרחוב ואת מספר הבית. משתמש אחר יידרש להזין בסדר הפוך. כמובן שגם הגדרות ה-VIEWS נדרשות להיות גמישות והמסכים דינמיים. גם כאן אני חושב על קבצי XML. עם זאת, ישנה סוגיה של קשר בין קבצי הקונפיגורציה, ולהזכירכם קיימות רמות הירארכיות שונות ביישות. הנטיה הנוכחית שלי היא לנהל ID ייחודי ברמות השונות של כל סוג יישות ואח"כ בהגדרות ה-VIEWS להגדיר ערך תואם (למשל, מחרוזת שמכילה שרשור של ה-ID של הרמות בנתיב). עם זאת, זה בעייתי ומזמין צרות, כיוון שאין שום דבר מובנה וקל שאוכף את זה, זה לא ממש קריא וקשה לתחזוקה. מצד שני, מספק את רמת הדינמיות והגמישות הנדרשת. מה דעתכם? התמונה מסתבכת יותר, כיוון שאני צריך לספק למשתמש גם מסכי חיפוש דינמיים. גם הגדרת מסכי החיפוש נדרשת להיות גמישה מאוד ובעלת VIEWS שונים (אותו קונץ של דפדוף של דפים) עבור משתמשים שונים. ואם לחתום את הסיבוך בשלב הזה, צריך לזכור שאת הערכים שמזין המשתמש יש לשמור וגם לחפש בהם. כמובן שרק DB בא בחשבון וכאן עולות הסוגיות הבאות – הקשר לקבצי ההגדרות, שמירה גנרית של סוגי ערכים שונים (אני חושב לנהל הכל כמחרוזת). לסיכום, אני צריך לנהל הגדרות ישות, הגדרות של מסכי הזנה, הגדרות של מסכי חיפוש. המסכים דינמיים, ההגדרות השונות עשויות להשתנות באופן תדיר, התחזוקה קריטית ולגמישות חשיבות מכרעת. אשמח מאוד לשמוע תובנות, הכוונות, הערות, עצות וכו'. אגב, האפליקציה WEB-ית, ומבוססת על FW3.5. מפתח ב-2008. תודה.
 

עידו פ

New member
כמה רעיונות

לגבי השמירה ב-DB, לא ציינת עם איזה DB אתה מתעתד לעבוד, אבל אם ניקח נניח שרת כמו sql server 2005, אתה יכול ליצור עמודות שמכילות XML ולתחקר אותן בשאילתא באמצעות xpath. אם אני מבין נכון, יש כאן כמה אפליקציות : 1. הגדרת מבנה ישויות - אפליקציה שבונה מבנה היררכי של ישות ושומרת את המבנה שלו באיזשהו XML. המלצה בנושא זה - לשמור את הישויות האלו ב-XSD (סכמה), ככה למעשה אתה לא "סתם" בונה XML אלא אתה בונה סכמה שבאמצעותה אתה יכול לאכוף קלט (מה גם שסכמה יותר מובנית להגדרה של שדות וטיפוסים ו-complex types אחד בתוך השני). דרך אגב - לבניה של סכמות יש כלים עצמאיים שמאפשרים בנית סכמה באמצעים גרפיים (אני לא מתכוון ל-Visual studio אלא לכלים יותר "נחמדים" ופשוטים) - אולי יהיה יותר פשוט למצוא כלי זול כזה ולרכוש רשיונות שלו עבור הלקוח שלך. 2. הזנת ישויות עפ"י מבנה הישות - בהנחה והלכת לפי סעיף 1' ובנית סכמה - אפשר לתחקר את הסכמה ולבנות מסכי קלט פשוטים המאפשרים הן קלט של complex type בסיסי והן קלט "רשומתי" (קליטת מספר ערכים בין אם הם פרימיטיבים או complex בפני עצמם) - זה דורש תכנון נכון של מסכי הקלט ושדות הקלט (מסכים ושדות שיודעים להיווצר באופן דינמי). החשוב הוא שכל שדה יתרום את המידע שהוקלד בו ל-XML הסופי שעליו תוכל להריץ את הסכמה ולראות האם ה-XML תקין או חסר (עד לרמה של שדות חסרים, כמות רשומות בן שהוזנו לרשומת אב, חריגה מערכי מקס/מינ וכו'). הנושא של ה-views השונים צריך לקבל טיפול ברמה של הגדרת אופן קליטת הנתונים - הגדרה שאומרת איזה שדות מוצגים באילו מסכים (לדעתי לא משהו שמגיע built-in ב-XSD, אבל אולי יכול להיות איזשהי הרחבה על ה-XSD מאחר וזה לא אמור להשמר ב-DB יחד עם הנתונים אלא יכול להשמר כנפרד) 3. מסכי חיפוש - מאחר ויש לך כבר סכמה (אם הלכת בגישה שהצעתי ב-1) אתה יכול לתחקר את המבנה ההררכי של ה-XSD ולייצר פקדים באופן דינמי לפי קבוצות ההרכיות. תצטרך לבנות קוד שיודע ליצור באופן דינמי פקדים על-פי הטיפוס של המידע ולהציג אותם בצורה הררכית (בניתי כזה משהו בעבר לההררכיה אחת, יחסית זה לא מורכב). היתרון שלך הוא שאם אתה שומר את המידע שלך כ-xml ב-DB, אתה לא צריך להתעסק עם שאילתות SQL מורכבות אלא אתה יכול לתחקר את המידע שלך ישירות ב-DB באמצעות XPATH (זה כמובן תלוי באיזה סוג DB תשתמש - ראה הערתי לגבי sql server 2005). אפשר לחשוב על עוד כל מיני רעיונות, זה כרגע על רגל אחת ...
 

misterG

New member
הצעה

אפשר לארגן הכל בDB באמצעות שתי טבלאות: אחת תכיל את ההיררכיה המוגדרת של המאפיינים, עם השדות (PROP_ID, NAME, PARENT_ID), וטבלה שנייה עם המאפיינים של כל הישויות, למשל (ID, PROP_ID, PROP_VALUE, ENTITY_ID). ככה יש לך בעצם עץ "ריק" של מאפיינים, וכל יישות צריכה להדיר ערכים לכל צומת או עלה בעץ. הכל נשמר בDB. שינוי בהיררכיה אינו מצריך שינוי של היישויות.
 
למעלה