שלום לכולם !

[TTTIS]

שלום לכולם !

אני מתעתד לפתח איזשהו רכיב המאפשר ממשק עבודה מול בסיסי מידע שונים ומשונים. בעיקרון כל ממשק יספק שרותי מידע לקליינטים ממגוון רחב של פלטפורמות וטכנולוגיות. חשבתי על להשתמש ב-Abstact Factory Design Pattern שיהיה ה-Core המרכזי. ה-Factory יחזיר ממשק לעבודה ע"י קריאה בשם שלו. כל ממשק יממש Interface ויחזיר שירות (אבסטרקטי) ע"י קריאה בשם השרות, ושליחה של אובייקט אבסרקטי כאינפוט של פרמטרים לשרות. למערכת תהיה עוד שכבה של WebService שתאפשר תמיכה בפלטפורמות אחרות. (כמובן שיש גם DAL). האם העיצוב נכון? חשוב לי לשמוע דעות נוספות בעניין. תודה מראש.

 

[TTTIS]

שכחתי לציין

C# .NET

 

[TTTIS]

ועוד דבר

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

 

[ייוניי]

קצת יותר פרטים אם אפשר

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

 

[TTTIS]

תגובה

מחלקת Factory מייצרת ממשק לקליינט (לדוגמא ASP.NET SITE). כל ממשק אמור לתת לקליינט גישה לקבל ולשלוח מידע לאיזשהיא מערכת מידע (לדוגמא MF). הקלאס שיממש את הממשק יבצע את האינטגרציה מול אותה מערכת מידע.

//ServiceFactory public static IServiceProvider GetServiceProvider() //IServiceProvider AbstactService CallService(string name, AbstactData input); //Client MFServiceProvider provider = (MFServiceProvider)ServiceFactory.GetServiceProvider("MF"); MFService service = (MFService)provider.CallService("name", input);​

המחלקה האבסטרקטית שנשלחת לממשק כאינפוט כרגע ריקה. המחלקות שיירשו ממנה יהיו מורכבות מאובייקטים הדרושים להפעלת השרות. כל האובייקטים והמחלקות שיורשות מהאבסטרקט הזה מחוללות ב-CG שכתבתי לצורך הפרוייקט (לוגיקה ב-DB + מילון פרמטרים). החילול בא לפתור בעיה של סטנדרט בכתיבה של האובייקטים. כל המערכת כרגע היא פנימית ובעתיד תחשף גם החוצה דרך WS (לא בדרישות כרגע).

 

[ייוניי]

-->

שים לב ש Abstract Factory הוא DP חזק מאוד שמטרתו היא בסופו של דבר להחזיר אובייקט ממחלקה לא ידועה (ידוע רק הממשק שלו אנחנו מצפים). ברגע שאתה עושה cast בקליינט למחלקה אתה למעשה מפספס את כל היתרונות של Abstract Factory. אבל מהתאור שנתת עד עכשיו לבעיה דווקא נראה לי שהקליינט לא ממש רוצה לדעת שמדובר ב MFServiceProvider... אם מטרת התשתית שלך היא להסתיר מהלקוח את פרטי המערכת אליה הוא מתממשק (על מנת לאפשר לו להתממשק באופן portabily ואחיד) אז מן הסתם הקליינט לא אמור להכיר את MFServiceProvider וטוב שכך. הייתי מחליף את AbstractService ו AbstractData בממשקים עם שמות מתאימים. אם אתה רוצה לרשת ממחלקה אבסטרקטית זה בסדר צור מחלקת AbstractService שתיישם את הממשק Service. כרגע זה נראה כמו סתם טרחה אבל תאמין לי שזה משתלם. עוד הערה קטנה לגבי Abstract Factory - אין ספק שזהו DP שימושי ביותר אבל צריך להיזהר לא להשתמש בו יתר על המידה. כלל האצבע הוא שעדיף כמה שיותר להעביר (לדחוף) אובייקטים למתודות וכמה שפחות להחזיר (למשוך). פקודה בסגנון: obj1.getObj2().getObj3().getObj4().doSomething היא בעייה תחזוקתית קשה מפני שהיא "כופה" יישום של מתודות רבות עבור כל יישום של ממשק obj1. אבל במקרה שלך אם תעצור ב AbstractService נראה לי שיהיה בסדר.

 

[TTTIS]

תגובה

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

 

[ייוניי]

בעקרון אני נגד CG

אמנם לא ממש הבנתי מהו הקוד שאתה מחולל ולמה הוא משמש אבל ב 99% מהמקרים אני חושב שאפשר להחליף CG ב Design פשוט וקל יותר לתחזוקה. ברגע שאתה מתחיל לעבוד עם CG שמכיל לוגיקה אתה למעשה מפצל לוגיקה שמקומה במחלקה אחת לשתי מחלקות לפחות - המחלקה המחוללת (פעיל) והמחלקה המחוללת (סביל). ברגע שחילול קוד הופך לשכבה אתה תצטרך לקבל החלטות לגבי האם שינוי צריך להעשות ברמת המחולל או ברמת הקוד שלאחר החילול ועצם ההכרח לקבל החלטה כזאת הוא הגבלה. אם תוסיף עוד פרטים לגבי אופי השימוש הספציפי (אופן השימוש האבסטרקטי מובן) בתשתית אפשר יהיה לדון על ההשלכות של CG לעומת Design חלופי.

 

[TTTIS]

OK

סכימה של שירות מורכבת מאובייקטים (יכול להיות אובייקט אחד ו/או <list> של אובייקטים). כל אובייקט מורכב מסט של פרמטרים (כולם סטרינג). שמות פרמטרים נמצאים בתוך טבלה (מילון) ב-DB. ניקח לדוגמא שרות GetProducts שצריך פרמטר CategoryName ו-CustomerName. הפרמטרים הנ"ל מרכיבים אובייקט שנקרא ProductsData. שרות אחר שנקרא GetProduct צריך פרמטר ProductName ו-CustomerName. הפרמטרים הנ"ל מרכיבים אובייקט שנקרא ProductData. מכיון שיש פרמטר שמקשר בין השרותים (CustomerName) ובין הסכמות של השרותים רציתי למנוע מאותו מתכנת להמציא פרמטר משלו כשהוא יוצר את המחלקה ב-Design. בצורה הזו, יש מילון פרמטרים ב-DB, פרמטרים לאובייקט, ואובייקט לשרות והכל מקושר. הקוד נוצר אוטומטית ואין תקלות.