WebForms או WinForms – מה עדיף?

WebForms או WinForms – מה עדיף?

Print Friendly, PDF & Email

פעמים רבות מספור נשאלתי את השאלה הזו ותמיד התשובה שלי היא זהה – כל אחת מהשיטות יש לה את הצרות והיתרונות שלה. בפוסט הזה אני מתכוון להסביר ולפרט אילו תועלות ויתרונות ומצד שני חסרונות יש לכל אפשרות.

ראשית, כדאי שאבהיר על מה אני מדבר: על מנת להסיר ספק, אני לא מתכוון לשימוש בשילובים שונים כגון Web Browser WinForms Control או שימוש באובייקטי ActiveX למיניהם. אלו יוזכרו בהמשך ביתר פירוט. עוד דבר, כאשר אני מדבר על אפליקציות WinForms אני מתכוון הן לאפליקציות בעלות ממשק משתמש גרפי (GUI) והן לאפליקציות בעלות ממשק שורת פקודה (Console) בלבד.

יתרונות בפיתוח חלונאי (לעומת WebForms)

– ריבוי מטלות – ניתן בקלות רבה לכתוב את האפליקציה באופן מרובה נימים (Multithreaded). ניסיונות לבצע דבר דומה ב-WebForms בדרך כלל בעזרת שפת סקריפטים כמו למשל Javascript יגיעו במוקדם או במאוחר לדפדפן תקוע עם הודעה על סקריפט אשר טרם סיים את עבודתו (תלוי במשך הזמן הדרוש לכל Thread לסיים את פעילותו).
– גישה לחומרה – רק מתוכנה חלונאית ניתן למשל לבצע סריקה מסורק, לבצע סריקת וירוסים, לקרוא ולשמור קבצים מ/אל המחשב או מיקומים ברשת או לבצע בדיקת תקינות לדיסק הקשיח.
– יכולת עבודה ללא תקשורת – נכון, זה נשמע די דבילי להזכיר את זה אבל אולי בכל זאת שווה להתעכב על זה דקה, אמנם, זה נכון לחלוטין שניתן לכתוב אפליקציות בטכנולוגיות Web ולהפעיל אותן במחשב מקומי בעזרת תוכנת שרת Web קטנה המותקנת במחשב (תוכנה כזו יכולה להיות IIS, Cassini ודומיהן), למרות זאת, היות ופעולות מסוג זה הן, בלשון המעטה, לא נפוצות ולכן לא נרחיב עליהן את הדיבור יותר מדי.

יתרונות בפיתוח Web-י

– ניהול גרסאות פשוט – היתרון ב-ה הידיעה של פיתוחים מסוג זה הוא בכך שהאפליקציה נמצאת במיקום מרכזי ועדכון שלה במיקום זה משפיע על כל משתמשיה באופן מיידי ללא כל צורך בפיתוח או יישום מנגנונים מיוחדים לעדכון האפליקציה בתחנות.
–  Multiple platforms support – זהו נושא מעט שנוי במחלוקת שכן מצד אחד, דף בסיסי מאד יוצג באופן זהה בכל דפדפן אך מצד שני דף מעט יותר מורכב כבר עשוי להיות מוצג ולהתנהג באופן שונה בדפדפנים שונים. כך יוצא שהיות ודפדפנים שונים נותנים תמיכה למערכות הפעלה שונות ולמחשבים מסוגים שונים דף שנכתב באופן גנרי מספיק יוכל להתנהג ולהיות מוצג באופן דומה בכל המקומות. אך כתיבת דף באופן גנרי מספיק איננה בהכרח משימה קלה. (לדוגמה נסו לכתוב קוד המחקה את אופן פעולתם של ה-IE Filters and transition effects כך שיוכלו לעבוד בדפדפנים שאינם תומכים ביכולות אלו)

לסיכום, אני הייתי מציע לבחון את התאמת טכנולוגיות הפיתוח של המערכת לצרכים העסקיים בשלבי האפיון המוקדמים (ככל האפשר) ובמידת הצורך לשלב ביניהן – למשל שימוש בטכנולוגיות כגון ActiveX באפליקציה Webית עשוי להעניק לה יכולות (ומגרעות!) מעולם התכנות החלונאי. באופן דומה, ניתן להשתמש ברכיבים דוגמת ה-Web Browser Control (במקרה של Dot Net) על מנת להעניק את היכולות מעולם התכנות ה-Webי לאפליקציה חלונאית. חשוב להבין שיש השלכות עסקיות של ממש לבחירה הזו, למשל, לפיתוח חלונאי קיים יתרון ברור במקרים בהם מבחינה עסקית נדרשת רמת תגובתיות גבוהה, יכולות תקשורת נרחבות (למשל יישום המצריך יכולת בתחנות העבודה לקבל באופן פסיבי שדרים מתחנות/שרתים אחרים או יישום המצריך יכולות הצפנה ופענוח ברמת התחנה). באופן דומה, לפיתוח Webי קיים יתרון ברור במקרים בהם נדרשת הפצה של הגרסה למשתמשים מרובים אשר משתמשים במגוון רחב של פלטפורמות ובמיוחד במקרים בהם נתונים אלו צפויים להיות גבוהים אך אינם ידועים למשל במקרה של שירות חדש כלשהו לציבור הרחב, היות ולא ברורה בדיוק כמות המשתמשים הצפויה וכמו כן לא ברור בדיוק מגוון הפלטפורמות בהן ייעשה שימוש בצד הלקוח, במקרה כזה יהיה נכון להשתמש בפיתוח Webי.

השאר תגובה