הקדמה

לאחר אין ספור כיתות לימוד שהסברתי להם את הכוח וה"יופי" של שפות Strongly Type , כשראיתי בפעם הראשונה את Anders Hejlsberg מציג את dynamic, הרגשתי תסכול רב ,איך הוא בא ומציג את dynamic ,שסותר תפיסה זו. הזמן עבר, וביקשו ממני להרצות על C# 4.0 ונוכחתי שוב,שהעולם לא "שחור ולבן"...

מתי להשתמש ב- dynamic?

כאשר אני רוצה לצרוך שרות שאין לי הסכם איתו (Interface משותף) או שאני לא מכיר את ה-,Type אבל אני יודע שיש לו מתודה שאני רוצה לעבוד מולה, dynamic יעשה את החיים קלים יותר.

דוגמאת קוד בלי dynamic:

דוגמאת קוד עם dynamic:

למידע נוסף על dynamic ניתן למצוא באינטרנט. ( בפוסט זה אני לא מנסה להסביר את dynamic לכל פרטיו )

הרעיון שלי לשיפור ה Dynamic

לאחר שנתים של עבודה עם dynamic הצלחתי להגדיר מה מפריע לי ואיך הייתי רוצה שמיקרוסופט יפתרו את הנושא.

קוד זה נראה רגיל אך לא... ה- ICalculator הוא Interface דינמי. כלומר GetCalculator לא חייב להחזיר מחלקה שמממשת את ICalculator .אלא, שיש לה חלק מהדרישות של ה- ICalculator. כלומר בואו נניח ש- GetCalculatorמחזיר מחלקה עם מתודה אחת בלבד ADD במקום 4 מתודות שמגדיר ה-Interface. במקרה כזה הקוד הנ"ל יעבוד, אבל אם גם הייתי משתמש בעוד מתודה כמו חיסור אז בזמן ריצה הקוד היה מקבל טעות (Exception).

איך מגדירים Interface דינמי?

למה זה טוב?

Dynamic Interface מתנהג בדיוק כמו dynamic רגיל. ההבדל הוא , שהצד שכותב בדוט – נט (צורך השירות) מרגיש שיש לו עבודה עם strong type interface ,על יתרונותיו, למשל , Intellisense. בנוסף, יהיה יותר קל לכתוב לזה TDD. אם חושבים על זה זה בדיוק כמו WCF, שני הצדדים, השרת והלקוח לא צריכים לממש אותו ממשק והם יכולים לעבוד אחד עם השני.

סיכום

כאשר אנחנו רוצים לצרוך שרות מ"עולמות אחרים" (Com,JavaScript וכו' ) אנחנו לא יכולים לכפות עליהם את תפיסת עולמנו, כמו למשל Interface ו-Base Class ולכן אנחנו עובדים עם dynamic אבל... אין שום סיבה שאת הצד שלנו בדוט-נט לא "נקשיח" ונגדיר לעצמנו חוזה על פיו אנחנו רוצים לעבוד.

כאשר WCF יצא הוא תוכנן לעבוד ב-SOAP. ורוב הדוגמאות היו לממש Interface שהוסיפו לו Attributes.

לדוגמא הקוד שנוצר שמתחילים פרוייקט ב-WCF:

ואז לרשת את ה- Interface ונוצרה לנו מחלקה שיכולה לממש כ-WCF Service. כאשר השוונו את זה ל- WS  רגיל (asmx) הטענה היתה,שזה הרבה יותר טוב כי אנחנו מגדירים את ה- Interface שמשמש גם לעולם הדוט-נט וגם לאיך יעבדו עם השירות (WSDL). כיום ב- WCF יש מספר רב של סוגים:

1.     WCF REST (JSON or POX)

2.     WCF Data Services (OData)

3.     WCF RIA Services

4.     WCF Web API

מהר מאוד אנחנו מגלים שלכל סוג אנחנו רוצים טיפה לשנות את ה- API כדי שיהיה יותר נוח לעבוד עם הממשק. מכאן הגעתי למסקנה הבאה:

1.     כל Getaway מתוכנן לעבוד מול פרוטוקול שונה וחושף את ה-API  הנוח לעבודה עם אותו פרוטוקול, למשל העבודה ב-SOAP  תיהיה שונה לגמרי מה-API  של העבודה עם OData.

2.     Getaway יכול לרשת מ- Base Class אבל אין עוד טעם לעבוד עם Interfaces ו- Attribute של WCF, כי ה- Getaway עצמו מגדיר את הממשק לעולם החיצוני ולא צורת מימוש לעולם הפנימי של דוט-נט.

3.     ה- Getawayיכירו רק את הממשק Ixxx , המימוש שלו יוזרק להם (Dependency injection( כלומר התפקיד שלהם זה לתווך בין העולם החיצוני לעולם הפנימי.

4.     כתוצאה מתכנון זה אנחנו יכולים להוריד את ה- Attributes WCF מהממשק Ixxx . היתרון: פחות צמידות לטכנולוגיה WCF.

סיכום:

כאשר יצא WCF  הוא תוכנן לעבודה עם SOAP  אבל כיום בעקבות ריבוי הצרכנים השונים של ה-Services כמו למשל Smart Phone למיניהם ו-JS  יש ביקוש לפרוטוקולים שונים לצריכת השרותים ועם API  נוחים יותר. שינוים אלו מחייבים אותנו לעשות חושבים ולבדוק אם מה שלימדו אותנו עד עכשיו בעבודה עם WCF  "מחזיק מים". אשמח לשמוע את דעתכם J.

ה-MVC עושה את החיים קלים מאוד בעבודה עם AJAX. להלן המצגת שהעברתי באחד האירועים:

תודה לכל מי שבא אתמול לשמוע אותי. עכשיו ניתן להוריד את המצגת והקוד מ-SkyDrive.

לחומרים נוספים העלתי ל-SlideShare.

לפרסומים שוטפים של מאמרים אתם יכולים להתחבר אלי לפייסבוק או לגוגל RSS.

שנה טובה.