Facebook
Twitter
RSSצפיות
תשובות
10 סיבות, מדוע לעבור לASP.NET2
להלן אציין עבורכם 10 סיבות עיקריות (יש עוד), מדוע כדאי לעבור ולפתח באינטרנט בשיטת ASP.NET בכלל ובגירסה 2 שלה בפרט.
1. כי ASP.NET עשירה באובייקטים מובנים (כמה אלפים), דבר שמקצר את הקוד שלנו ועושה אותו פשוט יותר, בנוסף, האובייקטים הללו מתורגמים לHTML בתקן XHTML ובשילוב CSS מלא, ומותאם דינאמית בזמן הפירוש לכל דפדפן בשוק. כמו כן, האובייקטים שמשתמשים באביזרי צד לקוח, כותבים קודי JS אוטומטיים, מבלי שהמתכנת יאלץ לעשות זאת.
2. כי ההתחדשות שלה דינאמית מאוד, הן על ידי מיקרוסופט עצמה, והן על ידי אגודות תוכנה המפתחות עליה אפליקציות. כל חודש ניתן למצוא חידושים מרעננים.
3. כי היא עושה יותר סדר בקוד, שומרת HTML ו- קוד לוגי בשני קבצים נפרדים לגמרי, מאפשרת אריזת קוד לשימוש קבוע, כאובייקט מושלם, מאפשרת ליצור קבצים שלימים של XML כדי לשמור על מידע ממסד הנתונים וכו'. כמו כן, ניתן לשלוט דרכה באופן מוחלט על IIS.
4. כי ASP.NET עוברת הידור קוד מלא, דבר ההופך אותה למהירה הרבה יותר מכל תקן או שיטה אחרת.
5. כי כדי לתכנת אותה, משתמשים בשפת תכנות מודרנית OOP, כמו #C או VB.NET המשוכללות, וכי תכנות בשיטת ASP.NET פותח בפני המפתח את העולם של התכנות הסטנדרטי באופן מלא. עושים סוף לשימוש בסקיפרטים מוגבלים. בנוסף, גם מתכנתי JS, JAVA ו- ++C יוכלו לפתח בה בקלות, אם ילמדו רק את תיאוריית NET. הפשוטה.
6. כי היא מתאימה מאוד לתיאורייה החדשה הקרויה WEB2 ותוכננו עבורה שלושה מנועי AJAX ייחודיים לה, כולם חינמיים, וביניהם מנוע ATLAS המאובטח והמהפכני של מיקרוסופט.
7. כי היא מדברת באופן מהיר יותר, מאובטח יותר ושוטף יותר עם כל סוגי מסדי הנתונים, ועם קבצי XML ו- XML SCHEMA. בנוסף לזה, היא שומרת נתונים בCACHE ומתקשרת מחדש עם מסד הנתונים רק כשיש שינויים או עדכונים.
8. כי סוף כל סוף מיקרוסופט מחלקת תוכנה מתקדמת בחינם (Visual Studio 2005) באתר שלה, תוכנה מאוד מתקדמת, המקצרת בשליש פיתוח אתרים, ומאפשרת לנהל קוד בצורה מעולה, והכל בחינם.
9. כי היא עושה סוף לצורך בלולאות קשות ומסובכות להצגת לולאת רשומות נתונים, או לבדיקת מידע בטופס. הכל נעשה אוטומטית על ידי פקדים מובנים בעושים אימות ופקדים מובנים שמתחברים לאובייקטי נתונים ויודעים לשלוף ולסדר היטב את הנתונים כמו בלולאה. בנוסף, ניתן לשלוט פרטנית על עיצוב השורות של הטבלה.
10. כי ASP.NET היא מגיבה לאירועים, ממש כמו JS, אלא שהיא מסוגלת להגיב לכל סוג אירוע שהגולש ייצור, ולהחזיר תגובה ישירות לשרת.
יש עוד המון יתרונות… אבל נסתפק באלו
28 תשובות
מה לגבי ההבדלים מ 1.1?
סעיף 1 – אני מצטער, אבל מהנסיון שלי עם הגרסא הקודמת, קוד JS שנכתב אוטומטית ע"י net. היה נחות משמעותית מהקוד שכתבתי בעצמי, מכל בחינה.
סעיף 4 – בגרסא 1.1 ההידור היה ל MSIL, ומשם היה עוד הידור בזמן ריצה. האם בגרסא 2 ההידור מתבצע לשפת מכונה, וחוסך את ההידור בזמן ריצה?
סעיף 10 – אני לא רואה שום יתרון בתגובה בצד שרת לארועים בצד לקוח, שניתן לטפל בהם בתכנות בצד הלקוח. לא היה בזה שום יתרון בגרסא הקודמת, למה פתאום זה הפך ליתרון?
ומה לגבי ה viewState המחורבן? מצאו לזה פתרון טוב יותר מאשר בגרסא הקודמת?
אני חושש שאתה לא צודק.
איני יודע אם יש שוני בכתיבה האוטומטית של קוד JS, אבל איני חושב שכדאי בכלל שמכונה תכתוב קוד כזה אוטומטי, אם אינך צריך זאת כחלק מהפקד עצמו.
פקדי NET פועלים אצלי מאוד מהר, והיות והפקדים הללו מכילים אלמנטי צד לקוח, אז הם כתובים אוטומטית. היו תוהגעתי מעולם התכנות הסטנדרטי לעולם תכנות אינטרנט, והיות וקלטתי את הקטע שם די מהר, הבנתי שיש לצורת כתיבות הקוד, הן בצד השרת והן בצד הלקוח, תוך שימוש מלא בפקדי שרת ולא בפקדי HTML, יתרונות רבים, שאני מעדיף לא לאבד. היכולת לשלוט עליהם היא מעולה, אם יודעים כיצד לתכנת אותם ידנית.
לגבי הידור:
כל עולם NET., עובד על העיקרון שJAVA – רק יותר משוכלל וכולל. הידור לשפת מנוע, ומנוע שמשלים אח"כ את ההידור. אבל איני מבין מה זה משנה לך.
ההידור הזה מתבצע פעם אחת בלבד, עד לשינוי התכנות של הדף. אם עשית היום דף ASP.NET, והעלת אותו לרשת, רק הגולש הראשון שיכנס אליו, יראה אותו איטי מעט. ההידור מבוצע פעם אחת לכל הגולשים.
ASP.NET שעולה לאט בפעם הראשונה לכל הגולשים לא מעיד על הידור, אלא על כתיבת קוד לקויה. כתיבת קוד לקויה תאיט אתר, ולא משנה באיזו שיטה הוא כתוב. אם אתה כותב קוד יעיל, אין שיטה שיכולה להתחרות עם מהירות של שפה מהודרת כמו ASP.NET.
לגבי סעיף 10: היתרון בתגובה לאירועים בצד שרת, אינה בפעולות שניתן לעשות בצד לקוח. אם אתה יכול לבצע תגובה בצד לקוח, מטופש להפעיל את השרת.
אלא, נקודת היתרון המהותית ביותר, היא בכך שהשרת לא צריך לקרוא בקשות HTTP. אם בשאר השיטות עבדנו על קטע של בקשה-תגובה, כעת התכנות מונחה על ידי אירועים וממילא לא שולח בקשה אחת ארוכה כמחרוזת HTTP, ולכן גם אתה לא צריך לעבוד עם request, אתה יכול להגיב לשינוי כל מאפיין של הפקדים, ואתה מקבל את הערכים אתה לא יכול לבצע בASP, או PHP תגובת אירוע כך: text1.font-size=1 (זאת דוגמה לא יעילה, אבל רק דוגמה).
מעבר לכך, התצורה הזאת מאפשרת לקבל מערכי נתונים מוכנים, לחסוך לולאות שקוראות את מסד הנתונים ועוד…
לגבי ViewState – גם בגירסה 1.1 וגם ב- 2 יכולת לכל פקד לבטל את מצב ViewState בפני עצמו, ויכולת לעשות זאת ברמת הדף כולו.
כך שמעצבן הוא לא, כי אפשר לבטלו לחלוטין. אבל יש לו יתרון עצום.
בו נגיד ויש לך קבוצת דפים השייכת לאותו מאמר שכולל טבלאות נתונים, תמונות ועוד… כל פעם שאתה לוחץ על הלחצן של הדף שאתה רוצה לעבור אליו, היית בתכנות בשיטות אחרות שולח לשרת request, ואז הוא היה שוב מעבד את הדף. בASP.NET הדפים יעלו מהר מאוד, היות ומרגע שטענת פעם אחת כל אחד מהדפים, VIEWSTATE שומר את כל המידע, כולל טבלאות הנתונים, ואז אתה מגדיר לדף, שאם הוא מבצע postback (כל משלוח הוא כזה), אז שלא יבצע התחברות למסדי הנתונים. הדף מצד אחד לא קורא שוב את כל התוכנה, מצד שני VIEWSTATE דואג שהדף חוזר למצבו המלא הקודם.
המשך…
כללית לגבי כמה הבדלים משמעותיים בין 1.1 ל- 2:
1. הוספת פקדים חשובים מאוד, לדוגמה:
נוסף פקד gridview המייצר טבלה מקושרת נתונים, שקישורה לנתונים יוצר באופן אוטומטי מיון וסינון, ללא צורך בכתיבת קוד שימיין או יסנן נתונים. מעבר לכך הפקד יותר מהיר מ- datagrid שהיה דומה לו בגירסה 1.1, וכך גם מאפשר בקלות רבה לקרוא לכל חלק ב- gridview, כל מאפיין וכל שדה המכיל נתונים, בזמן ריצה, עם פחות קוד.
2. עבודה נוחה יותר עם יצירת קבצי dataset נפרדים – אחד ההבדלים העצומים בין ASP.NET לשאר השיטות, הוא השימוש במערך קישור נתונים חדש בשם ADO.NET. הפקד הזה יודע ליצור מערכים שנקראים datasets והם למעשה קבצי XML וירטואליים שמסוגלים להוות העתק גם למסד הנתונים כולו ובמלואו, או לכל חלק ממנו וכל סוג מידע שנחפוץ (כולל קשרי גומלין, מפתחות, שאילתות, חוקים וכללים ועוד). בגירסה 2 יש שיפור עצום בעבודה מול קבצים כאלו. יצויין כי עבודה עם DATASETS מאובטחת מאוד, כי מסד הנתונים נפתח לרגע, ונסגר מיד לאחר שהDATASET מתמלא, ומאותו הרגע העבודה היא מול קבצי XML שהם העתק מסד נתונים.
3. objectdatasource – פקד שמפעיל את gridview וכעת גם את שאר פקדי הנתונים המקושרים. קישורו מאפשר לקשר בין קבצי XML, סכמות XML, וקבצי dataset השואבים נתונים ממסדי נתונים, לבין פקדי הנתונים כמו gridview. הפקד מפעיל את קובץ ה- dataset ואחרי מילוי, הפקד שואב את ה- XML והסכמה שלו. הפקד הזה יודע בלא צורך בתכנות לחבר את הנתונים ולהציג אותם בפקדי הנתונים, וכן הוא ממיר את השאילתות באופן אוטומטי וללא התערבות מתכנת, לשאילתות UPDATE, INSERT, DELETE – לפי בחירתנו. לנו כל שנותר, הוא לאשר לו לבצע זאת, ולסמן לו בהגדרת המאפיינים, אילו שאילתות הוא יבצע ואילו לא.
4. sqldatasource – אובייקט נוסף שבשונה מקודמו, יודע לבצע בלי DATASET פקודת SELECT אחת אוטומטית על מסד הנתונים, להציג בטבלה את התוצאות, ולאפשר לפי בחירתנו, עדכון שלהם.
5. קובץ WEB.CONFIG משופר. השליטה על IIS טובה מפעם דרך הקובץ הזה, וניתן להגדיר בתוכו את כל מחלקות ה-NET שנרצה להשתמש בהם בדפים, בלי להגדיר אותם על כל דף ודף.
6. הוספת אפשרויות אימות נתונים אוטומטית.
7. אפשרות כתיבת קבצי sitemap שמסוגלים למפות את האתר בסיוע XML.
8. אפשרות כתיבת קבצי master page המסוגלים להציג תבנית קבועה של תצוגה, שעל גביה יוצגו כל שאר דפי האתר או חלקם.
יש עוד שיפורים רבים…
בברכה
אביעד
אז אני אנפץ לך אשלייה
ברגע שאתה פונה לשרת הווב אתה מבצע בקשת HTTP, ולא משנה לך שזה תכנות מכוון אירועים מהבחינה שלך, זה מה שקורה, המנוע של ASP.NET יודע לנתב את הבקשה למתודה המתאימה, זה מה שקורה בסה"כ. אז אמנם אתה לא עובד ישירות מול בקשת ה-HTTP (למרות שזה גם יכול להוות חסרון, כי לפעמים בתכנות צד שרת רצוי לעבוד Low Level)
ה-viewstate אולי עובד בצד השרת, אבל הדפדפן ימשיך לרנדר שוב ושוב את העמוד, אלא אם תשנה תכנים בצד הלקוח בעזרת JavaScript (אם זה מידע מהסרבר יש כאן צורך לשימוש ב-AJAX).
הצחקתני!!!
ניר יקירי.
נכון, הבנתי שאתה מתכנת ותיק וראוי, אבל יש עוד כאלה בחיים.
אתה גם תופתע לגלות, שהפלא ופלא, למרות שהיית בטוח אחרת, גם הם יודעים את הדברים.
א. אין דרך לשלוח באינטרנט בקשות כיום ללא פרוטוקולי תקשורת מקובלים.
ב. ברור שגם ASP.NET לא המציא פרוטוקול תקשורת חדש, אחרת היה צריך להתאים את הדפדפנים בדרך שונה אליו.
ג. אלא, שASP.NET שיכללה וייעלה את דרך ניהול הבקשות הללו, כך שהיא דואגת להמיר אותם אוטומטית לפורמט ולפקד המתאימים. והיא מפעילה בצד השרת שיטה, שיודעת מה היא שלחה ומה היא מצפה לקבל, ולאיזה פקד.
ד. רוב העברת הנתונים של ASP.NET לא מבוצעת בTCP/IP אלא בSOAP שגם הוא עובד דרך אינטרנט.
לגבי viestate איני יודע על מה אתה מדבר.
viewstate הוא בצד לקוח בכלל. אם תפתח אתר שכתוב NET. וVIEWSTATE מופעל, אתה תראה שהדף מכיל כל מיני פקדים מסוג HIDDEN עם טקסטים לא ברורים. זה השיטה לשמור VIEWSTATE. כמובן שהוא פועל במקביל לתגובת שרת, אבל חלקיו מורכבים משניים.
חוץ מזה, כל עניינו הוא אך ורק שמירת ערכי הפקדים הקיימים. אין לו מטרות אחרות.
שמע
תאמין לי שאני מכיר מתכנתים שהם בהרבה יותר תותחים, ותיקים וראויים ממני, שאני אפילו לא מתקרב לרמה שלהם.
אבל:
"רוב העברת הנתונים של ASP.NET לא מבוצעת בTCP/IP אלא ב שגם הוא עובד דרך אינטרנט."
שאתה עובד מול שרת ווב אתה משתמש במנגנון ה-HTTP.
זה סוג של פורמט XMLי שאתה משתמש בו בתור תוכן בבקשת ה-HTTP (או בקשות אחרות) עבור תקשורת עם Web Services. אתר אינטרנט לא בהכרח חייב להשתמש ב-Web Service אפילו כשהוא עובד על ASP.NET.
"viewstate הוא בצד לקוח בכלל. אם תפתח אתר שכתוב NET. וVIEWSTATE מופעל, אתה תראה שהדף מכיל כל מיני פקדים מסוג HIDDEN עם טקסטים לא ברורים. זה השיטה לשמור VIEWSTATE. כמובן שהוא פועל במקביל לתגובת שרת, אבל חלקיו מורכבים משניים."
אכן, אני אראה אותו כ-hidden input ומשום כך אין לו שום חשיבות לדפדפן, מצידו זה סתם טקסט שאתה שולח בין בקשות ולא רוצה להציג למשתמש. הASP.NET בשביל לשמור על ה-state של הפקדים משתמש בזה כך הוא יודע לאתחל מחדש את הפקדים בכל פעם שאובייקט הדף נוצר.
לדעתי, עליך לקרוא שוב על איך האינטרנט פועל, על פרוטוקול ה-HTTP ועל איך ASP.NET משתמשת בפרוטוקול, כדי לבצע את מה שהיא מבצעת.
ניר… ניר… ניר…
איני יודע למה אתה כל פעם כותב דברים שידועים. מדוע? כדי להראות שאתה יודע?
השתכנעתי כבר קודם.
1. פרוטוקול SOAP הוא פרוטוקול העברת טקסט בצורת XML.
בקשות HTTP, ואני חוזר, הן הדרך היחידה ליצירת תקשורת בין שרת ללקוח, גם זה ברור.
עכשיו, כאשר בקשה מגיע בHTTP , היא מגיע דרך מחרוזת. אלא מה, שלמחרוזת הזאת יש ערך טקסטואלי. אבל, עובדה היא שASP.NET, יודעת מכל פקד, איזה ערך הוא צריך להכיל ואיזה ערך הוא הולך להחזיר, והיא עושה את זה, דרך קבלת הנתונים בצורת XML מלא. בתוך ה- XML מוגדר בדיוק כיצד אמורים לטפל בנתון, וכך אפשרי היה לבנות מערכת מונעת אירועים כראוי.
אותך, אותי, את המתכנתים של ASP.NET כל זה הוא תיאוריה ולא אמור לעניין יותר מדי, היות ועד עתה, היית צריך לבקש את הנתון מן המחרוזת, להמיר אותה, להתאים אותה לאן שהיא שייכת, ואם הייתי רוצה לבחון אותה בצד שרת, רק אז הייתי יכול.
בASP.NET היא עושה ומכינה הכל למצב הזה עבורך.
לגבי VIEWSTATE, אני מנסה להבין – מאוד מנסה להבין מה אתה רוצה מהתכונה הזאת.
הבהרתי לך כיצד הוא פועל, ואני עדיין מנסה להבין מה אתה רוצה לטעון לגבי חיסרון שלו. אולי תסביר מה יש לך נגדו ומה הקשר בין צורת הפעולה שלו לטיעון שטענת בראשונה?
הממ…
לגבי ההידור – asp.net עובד בדיוק באותה השיטה של jsp – מיקרוסופט לא המציאו שום דבר חדש כאן. הרי גם jsp מתהדר ל servlet בהרצה הראשונה שלו, וההידור ל MSIL מקביל להידור ל IL של java, וה CLR מקביל ל JVM. לכן אני לא רואה הרבה יתרון ל asp.net על jsp בנקודה הזו. מישהו בטח כבר עשה השוואה של יעילות בין MSIL ל IL של java. רק צריך לחפש אותה…
לגבי סעיף 10, אני חייב להסכים עם ניר – השרת קורא בקשות http, גם אם למתכנת נראה שהוא עובד ישירות מול אובייקטים בדף – מהסיבה הפשוטה שפרוטוקול התקשורת בין השרת ללקוח הוא http – וד"א, גם soap מבוססת, בסופו של דבר, על http.
אז נכון שלך, כמפתח, הרבה יותר נוח לגשת ישירות למאפיין או מתודה של פקד שהגדרת, אבל זה לא אומר שכך מתבצעת התקשורת. אולי בעוד כמה דורות של דפדפנים, כשהכל יהיה מבוסס ajax, זה יעבוד ככה. כרגע הכל מבוסס http, מה שאומר שכשאתה ניגש למאפיין של פקד בצד השרת ורואה שהוא השתנה כתוצאה מפעולה של הלקוח, אתה בעצם ניגש בעקיפין ל http request האחרון שנעשה, ושולף משם את המידע.
לגבי view state – עצם הרעיון מחריד אותי.
זהר… אני ממש לא מבין את הטיעונים.
1. ידוע שגם JSP עושה זאת, אבל בשיטה אחרת. זה לא חדש לאיש שמיקרוסופט לא ממציאה אף גלגל מחדש. היא משכללת דברים של אחרים וגונבת לעצמה. אבל זה עדיין משוכלל יותר, ובמקרה הזה יעיל יותר (בדיקת הרצה של אתר מקצועי שקראתי, הריץ קוד בעל מאפיינים זהים בשני המנועים וראה יתרון מהירות לASP.NET).
2. אתה יכול להסכים עם ניר מהיום ועד מחר – זה קטנוני ולא בוגר, היות ורשמתי איך המערכת מתייחסת בסופו של דבר. יש לי חדשות בשבילך: גם AJAX שולח בקשות HTTP, בסגנון שלו. אין דרך אחרת להעביר בקשות.
כל הדיון נדוש. מדוע?
כי כל הנסיון שלך לצמק ולהקטין את ASP.NET הוא קלוש.
בסדר… כולנו מודים הרי שהגישה היא בסופו של דבר על ידי בקשות HTTP.
בוא נחשוב, איזו מערכת משוכללת יותר:
1. מערכת ששולחת בקשות ומצפה ממך לתכנת קוד שילכוד אותן מתוך המחרוזת, בצורת מחרוזת?
2. האופציה השניה הוא קוד שרת שכשהוא שולח את הפלט וממתין לקלט, הוא מציין לעצמו את כל המאפיינים של כל פקד וכל נתון שהוא מצפה לקבל ממנו, ואח"כ בקלט החוזר, הוא מבצע לבד את הREQUEST כך שהוא מכין לך את כל הנתונים שהגדרת לו, לעבודה מושלמת מול הפקדים שלך בשיטת "מטפלי אירועים" המעולה מתכנות שפות מטופלות אירועים.
לכן, אותי מעניין לשמוע ממך או מניר, טענה ממשית, כיצד הטיעון הזה משפיע מעשית כנגד ASP.NET. בבקשה. להזכירכם, גם בNET. ניתן לשלוף נתונים מבקשותץ HTTP בצורה הישנה, לצד שימוש בצורה החדשה, האוטומטית.
לגבי תגובתך על VIESTATE, התואיל להסביר לנו הסבר קצת יותר חכם?
זהר וניר היקרים.
אף אחד לא חייב אתכם להתחיל לעבוד עם שיטות חדשות ומודרניות. אתם יכולים להמשיך להיות מבסוטים מתכנות דף קובץ יחיד, עם בלאגן קוד מעורבב HTML ו- ASP או כל שיטה אחרת, ולכתוב קוד באורך כפול ולהיות מאושרים מאוד.
אבל לקהל הגולשים שלנו יש את הזכות לחשוב בהגיון ולבחור, האם לדעתם לתכנת 1000 שורות קוד ולפתוח עשרה RECORSETS לא מאובטחים, עדיף על פני כתיבת 200 שורות שעושות יותר פונקציות, ועובדות מול קובץ DATASET יחיד, מהודר, שמבצע את הקריאה למסד נתונים בשרת עצמו באופן מאובטח?
בברכה
אביעד
מממ…
אני לא יודע בדיוק מה הניסיון שלך לפני שהגעת לתחום הדוט נט, אבל לי זה דיי ברור שלא הגעת מתכנות בטכנולוגיית צד שרת אחרת כמו ASP, PHP או JSP.
אם היית מגיע דרכם (או אפילו חוקר עליהם קצת) היית רואה שאין אנו עובדים עם ROW TEXT אלא שאנחנו גם עובדים עם אובייקטים, שטיפלו בעבורנו בבקשה וסדרו לנו אותה (אתה מוזמן לראות את ה-API העשיר של JSP למשל בנושא הזה).
בזמן שאתה עובד עם פקדים אנחנו עובדים ישירות עם אובייקט שמחזיר לנו נתונים מהודעת ה-HTTP.
ב-ASP/PHP/JSP אנחנו עובדים ישירות דרך אובייקט הRequest שמנוע ה-ASP/PHP/JSP כבר הכין עבורנו וקיימים בו שיטות ומאפיינים לקריאת ה-headerים השונים בצורה נוחה, הפרמטרים השונים. זה נקרא Low level ליד ASP.NET, אבל אנחנו לא מתכנתים מספיק Low level כדי לכתוב/לקרוא ממש את הודעות ה-HTTP בעצמנו, זה למה יש ASP/PHP.
ב-ASP.NET כפי שאני מבין את זה, יש עוד שלב שבו המידע מתוך אובייקט ה-Request מאתחל את הפקדים במידע והמאפיינים של הפקד נקבעים לפי המידע שמגיע מה-viewstate שנמצא באובייקט ה-Request.
——–
אני רק מתקן את הטיעונים הלא נכונים שלך כמו "רוב העברת הנתונים של ASP.NET לא מבוצעת בTCP/IP אלא בSOAP שגם הוא עובד דרך אינטרנט." או "אלא, נקודת היתרון המהותית ביותר, היא בכך שהשרת לא צריך לקרוא בקשות HTTP"
אין בכוונתי להוריד מערכה של ASP.NET כטכנולוגייה לפיתוח אתרים.
יש מבין?
אני אתחיל מזה שאי אפשר להשוות JSP
עם ASP.NET
זאת משום שמדובר בשני מנועים שונים לגמרי.
ה-ASP.NET עובד עם ה-CLR של MS ועובר דרך ה-IIS (שהוא שרת שמקומפל לשפת מכונה) ו-ISAPI (שגם מקומפל לשפת מכונה)
מה גם שה-CLR לא עובד בשום פלטפורמה מחוץ לפלטפורמות של MS, כך ש-MS יכולה לעשות טוויקים משלה ל-CLR כך שיהיה יותר יעיל (מי מכיר יותר טוב מMS את ווינדואס)
לעומת זאת ב-JSP אתה עובד עם ה-JVM של סאן (ב-99% מהמקרים) ועובד דרך שרת אפליקציות מסויים (לא חובה להשתמש בתוכנת שרת מסויימת, יש לך בחירה גדולה בין הרבה מאוד שרתים, שלא נדבר על כך שאתה יכול לבחור לעבוד עם שרת שמריץ רק JSP/Servlets לעומת שרת שהוא container שללי ל-J2EE שזו פלטפורמה מפותחת ביותר). הJVM עובד גם על כל מערכת הפעלה וכידוע פורטבליות עולה ביעילות.
זה למה אי אפשר להשוות את JSP עם ASP.NET ביעילות.
ותמיד אתה יכול לבצע הפרדה בין מידע לעיצוב. תלוי ברמה שלך ובניסיון שלך.
(למשל פעם חשבת להשתמש ב-XML ו-XSL בשביל זה? זה פתרון מאוד קל ונוח)
נו… ושוב המגננה… יש טובים ממך.
כעת, לפי שכתבת, ברור לי שחשבתי לשוא על יכולותיך.
חוסר הידע שלך, שאתה מתעקש להשתמש בו ללא הרף…
הנסיון הדמגוגי שלך בדיון לנבא מאיפה מגיע כל מתכנת.
והעובדה שאתה לא קורא, וגם מה שאתה קורא אתה לא מבין בדבריו של האחר, רק בגלל שהם נוגדים את דיעותיך.
1. הרקע שלי התחיל בVB5/6 ומשם עבר לשנתיים בASP, ואח"F עבר לASP.NET.
אני שמח ומאושר שאני הייתי קודם מתכנת אפליקציות ואח"כ באינטרנט, כי אין לי את החשיבה המצומצמת שלך, שחושבת רק על סגנון הבקשה תגובה.
אם היית קורא כאן את מרבית הסיוכ שלי לגולשים, היית מבין שכל הידע הזה שאתה רוצה ללמד אותי בASP, יש לי , יותר (כן, כשילדים מנסים לפתח עלי דמגוגיה בידיעות שלהם, אני מגיב כך. מצטער).
לASP ישנם תשעה אובייקטים מובנים עיקריים לעבודה בין השרת ללקוח.
לASP.NET יש מאות כאלו.
האובייקט request קיים גם ב- ASP.NET, ואם שלחת בטופס נתון ששם המשלוח הוא ID, אז אם תבצע request.Form("ID") תקבל את התשובה בדיוק כפי שתקבל אותה בASP.
עכשיו ניר, אני ארצה להציב אותו במסד הנתונים בשדה שמוגדר כ- INTEGER, אז אני אצטרך להמיר אותו לINTEGER. אם הוא תאריך, אני אצטרך לפרק ולהרכיב אותו מחדש, וכך הלאה.
לעומת זאת, ASP.NET עושה את כל זה לבד בשבילך.
במקום לבצע request ואח"כ לעבוד ולהמיר אותו, ואח"כ לבצע בו עוד פעולות התאמה.
אני יכול לבחור אם לקבל אותו ולבצע עצמאית REQUEST, או לקבל אותו כבר ארוז ומוכן, כINTEGER או כסוגו המקורי, בתוך הפקד, מוכן להמשך עיבוד מתקדם.
המצחיק זה, שאתה מדבר על אובייקטים, בעוד ASP.NET פותחה עם OOP מלא.
2. JSP ו- ASP.NET פותחו על אותו רעיון, רק ש- ASP.NET הרחיבה יותר ושכללה יותר את עיקרון העבודה באינטרנט, והוסיפה יותר עבודה מונחית אירועים.
3. גם את תעמוד על הראש לא יעזור לך. ASP, PHP והאחרות משתמשות בהעברת בקשת HTTP בצורת מחרוזת טקסט ארוכה, שפקד REQUEST נבנה כשהוא יודע לפרק אותה. היות ו- ASP.NET יודעת בדיוק גם את סוג הנתונים שיוחזרו מהפקד, וגם מידע נוסף, הרי שASP.NET מעבירה את הבקשה ומקבלת תגובה בצורת XML, ולא מחרוזת טקסט. זה בדיוק כוחה.
4. כל מה שאתה כותב על VIEWSTATE הוא חסר טעם. VIEWSTATE יוצר פקדי HIDDEN, מקודדים (כדי שלא יחשף מידע), ששומר את מצב הנתונים הנוכחי. מה קורה?
ברגע שמבוצע אירוע המוגדר כבעל תגובה בשרת, השרת כאחת הפעולות מבצע שדרוג של פקד HIDDEN הזה, עם הנתונים החדשים.
כלומר, הנתונים של VIEWSTATE, שמורים אך ורק בדף עצמו כפי שהוא אצל הלקוח – לא בשרת , לא בCACHE….
אדון ידען, כדאי לשמור קשר לדיון.
1. כל מה שהשוו, ואת זה כתבתי, זה מערכת שנבנתה גם בASP.NET וגם ב- JSP, ועבדה על שני שרתים מקבילים, ולא על אותו שרת. שרת JSP עבד עם J2EE, וASP.NET עבד מול NET. גירסה 2.
לא דיברתי על עדיפות, לא דיברתי על רב גוניות, דיברתי על זה, שבכל הבדיקות, ASP.NET הגיבה מהר יותר וטיפלה מהר יותר בכל האירועים והבקשות.
זה אפשר להשוות. אם יש לי שרת מיקרוסופט, לא מעניין אותי שהפיצוי על המהירות הוא היכולת שלי להתאים את JSP לכמה מכונות אפשריות. מעניין אותי שאני ארצה שהשרת שלי יגיב ויטפל בעניינים הכי מהר.
אז אני לא מבין את המהלך התרצני שלך.
2. אני אכריז כבל עם ועדה: בכל שיטה, אפשר לעשות הכל מכל כל. את מה שASP.NET עושה, אפשרי לעשות גם עם ASP, גם עם JSP.
בהסתייגות אחת: אם בא לי ונחמד לי לכתוב פי שלוש שורות של קוד.
אני שמח שאתה רוצה ללמד אותי מה זה XML, XSL וכו' (אתה כנראה שוכח שכשעובדים עם ASP.NET חייבים להכיר אותם היטב, אם רוצים להצליח לשלוט בחלקים באוטומציות שלה).
אז קודם כל XSL יעילה להיות גיליון העיצוב של XML. ASP.NET עובדת עם XML ומולה XML SCHEMA. מה עדיף?
1000 שורות קוד, והסתבכות בכתיבה ידנית, או 200 שורות קוד שעושות יותר, וקוראות וכותבות XML + XML SCHEMA, באופן אוטומטי?
ניר, מותר לומר שאין לך מושג איך עובדים עם ASP.NET, שאתה חושש, שאין לך כח ללמוד דברים חדשים, ולכן אתה מאוד מאוד רוצה להצדיק שימוש בכל שיטה אחרת כאילו אין שינו יטוב יותר בASP.NET.
בינתיים לא שללת שום יתרון שכתבתי.
אני לא מנסה לצמק את asp.net.
אני חושב שיש בטכנולוגיה הזו יתרונות רבים על הרבה טכנולוגיות אחרות.
אבל מצד שני, יש לה גם חסרונות רבים, שבאים לידי ביטוי במספר דברים, כמו לדוגמא, בסעיף 10 של ההודעה הראשונה שלך – תגובות של השרת לפעולות של הגולשים. זה לא יתרון, ולא משנה איך תהפוך את זה. באפליקצית רשת אופטימאלית, השרת צריך להיות החלק שעובד הכי פחות מכל שאר החלקים במערכת.
לגבי קלות הפיתוח של asp.net, זו חרב פיפיות, אבל זה נכון לכל טכנולוגיה שמאפשרת פיתוח wysiwyg, בעיקר בחלקים התכנותיים – אני מסכים איתך שאין פשוט ומהיר יותר מאשר לגרור אובייקט dataset למסך ולהגדיר את החיבור שלו למסד הנתונים דרך ה wizards של ה vi.net, ואין ספק שלמתכנתים מנוסים זה יכול להיות יתרון שמתבטא בקיצור זמן הפיתוח ובהשקעה של הזמן הזה בדברים החשובים באמת, אבל מצד שני, זה מתבטא בקוד זוועה אצל מתכנתים פחות מנוסים, שבסופו של דבר משתמשים ב wizards האלו בלי לדעת מה בעצם קורה מאחורי הקלעים, ולכן אתה גם רואה אותם אח"כ שואלים שאלות שאתה ואני נרצה לענות עליהן ב RTFM. זו לדעתי הבעיה הגדולה של מיקרוסופט – הם מגדלים דורות של פסאודו-מתכנתים, שהרמה התכנותית שלהם שואפת לאפס.
לגבי ה viewState, הוא מזעזע פשוט מעצם זה שהוא מיותר לחלוטין. בתור אחד שמפתח net., אני מניח שיצא לך להסתכל על קוד המקור שנוצר בדפדפן מטופס שיש לו viewState. אתה מקבל את ה hidden הזה עם המחרוזת האינסופית הזו, כאשר בסופו של דבר, היא גם נשלחת לשרת על כל postback (וכבר הסכמנו על זה ש asp.net אוהבת postbacks בצורה מוגזמת), ומכבידה על התעבורה וכן, גם על זמן הריצה של השרת, כי אחרי הכל, צריך גם לפענח את המחרוזת הזו ולקשר את הנתונים לאובייקטים וכו'. אז נכון שהמנגנון של asp.net עושה את זה בשבילך, אבל זה עדיין עולה לך בתוספת מיותרת ומכבידה לתעבורה, ובתוספת זמן בפיענוח הדף.
לגבי ajax זה נכון, בסופו של דבר ajax זה באז-וורד לתכנות בצד הלקוח בעזרת httprequest.
אני רוצה גם להתייחס למה שכתבת לניר, על הצורך של מתכנתי asp/php וכד' להתעסק ישירות מול אובייקט reuqest ולהמיר מחרוזות וכד'. אני לא אגע ב php פשוט כי אני לא מכיר את הטכנולוגיה, אבל קח בחשבון ש php גם היא oo, ולכן ניתן (וסביר להניח שמישהו כבר עשה את זה) לבנות בה אובייקטים שיטפלו בכל הנושא של בדיקה והמרת משתנים, באופן שיאפשר עבודה פשוטה וקלה עם זה.
כשאני מקבל משתנה מה request ב asp, אני אמנם מקבל אותו כמחרוזת, אבל מכיון שאני כותב asp שמבוסס על js, אני משתמש בהרחבה פשוטה של אובייקט String בעזרת prototype שכתבתי די מזמן כדי לבדוק ולהמיר את הערך לערך הנכון שלו.
ככה שיוצא לי קוד כזה, בערך:
var dTheDate = Request.Form("theDate")().forDate();
var iInt = Request.Form("int")().forInt();
אז נכון, זה לא בדיוק אותו דבר כמו לקבל את הערך כבר מפורמט, אבל מצד שני, גם העבודה עם המחרוזת לא הופכת להיות כזו מסורבלת.
קח בחשבון ש js היא גם oo, והיא תומכת גם בירושה, לדוגמא, ותגיע למסקנה שגם ב asp ה "קלאסי" ניתן לתכנת oo בצורה קלה ופשוטה, מה שאומר שמתכנת עם מספיק נסיון יכול לבנות לעצמו מחלקות שלמות שמטפלות בכל מני דברים. אמנם לא להגיע לעושר של הספריות של net., אבל מצד שני, בכמה אפליקציות net. משתמשים במאית מהספריות האלו?
בשביל מה סתם לומר?
אני לא מבין למה אנחנו ממחזרים טענות, ולמה אתה ממשיך להביא לי טיעונים שכבר הגבתי עליהם באופן מלא, ותירוצים שהם נראים כחוסר הכירות וחוסר רצון להכיר וללמוד.
1. תגובות מונחות אירועים ואובייקטים הן יתרון, והן יתרון והן יתרון, ואני אחזור לומר זאת חמישים פעם. ההבדל בינינו, שאני כבר הבאתי הדגמות הגיוניות, ואתה משתמש בשיטת הפרופסור, המסתפק באמירה "אני מוכשר" כדי לשלול בלי סיבה.
אז בפעם החמישית, וישפטו כל הגולשים כאן:
ברגע שיש פעולה שהשרת צריך לעשות, ויש לי שתי דרכי פעולה אפשריים:
א. לבצע request ידני, כאשר העובדות בזה הן:
* request מושך נתון מסויים מתוך string ארוך של HTTP.
* באחזור נתון מrequest, אין יותר שום קשר בינו לבין הפקדים ששלחו את בקשת הHTTP.
* request תמיד מופיע כנתוני מחרוזת, ולכן צריך לבצע לו המרות מלאות.
* כדי לשאוב מאפייני עיצוב ראשוניים השמורים במסד נתונים וכד', אני אצטרך לעשות זאת על ידי קוד ארוך.
ב. אפשרות שניה, להתייחס לנתון שלי, בהתייחסות ישירה לאובייקט ששלח אותו, שואליו הוא קשור:
* קבלת הנתונים אינה במחרוזת, אלא אסינכרונית על ידי XML שמסודר בצורה היררכית, ומתוך כך יודע לתאר באופן מושלם את צד הלקוח ששלח את הבקשה, ולפרט את הבקשות לפי זה.
* האחזור של הנתונים קשור בקשר ישיר עם כלל שיטות ומאפייני האובייקטים, הן בצד הלקוח והן בצד השרת. זאת אומרת שאני לא רק יודע איזו תיבת טקסט למשל, שלחה את המספר 1, אלא גם באיזה צבע היה המספר 1 כשהוא נשלח, באיזה עיצוב, והאם זה אמור להשפיע עליו או לא ועוד ועוד ועוד…
* אין לי שום צורך בקוד ארוך. הגישה לכל המאפיינים והפקדים, בדיוק כמו כל שפת OOP, באופן ישיר.
* הנתונים מאוחזרים ומתקבלים על ידי הלוגיקה, כשהם כבר מוגדרים וממויינים לסוגיהם (string' integer וכו').
אז מה יותר קצר? מה עדיף?
הטיעון שהעלית, שטוען שתגובות שרת לאירועים זה בעייתי, כי אתה רוצה למעט פעולות בשרת, ממש לא שייך. ASP.NET תעבוד עם JS אוטומטי שלה, או ידני שלך, ללא הגבלה כלשהי. כל מה שהיה נכון עם צד לקוח עד היום, נכון גם עם ASP.NET.
אין שום סיבה שASP.NET תבצע אירועים של צד לקוח בצד שרת, ולכן היא מחולקת לשתי קבוצות אירועים: 1. server events ו- 2. client events
אני מנצל זאת כדי לתכנת דפים גלובאליים עם מסד נתונים המאפשר התרחבות, ואז אני גמיש מאוד, ויכול לשנות את עיצוב הדף על פי הדף הנפתח שביקשתי, וכל זה בדיקנות על ידי השרת.
2. קלות פיתוח:
פיתוח wysiwyg זה פיתוח שאתה רק מצייר ומקבל תוצאה כתובה של HTML. הוא לא פיתוח הקשור לתכנות. כל תוכנת פיתוח טובה מאפשרת גם ב- ASP גרירות והגדרות על ידי תפריטים. אלא, שבגלל יכולותיה של ASP.NET, אז ממילא יהיו יותר פונקציות ותפריטים, אבל גם לו נכתוב קוד ASP או PHP ומולו קוד ASP.NET – כולם יכתבו בפנקס הרשימות ובאופן ידני, עדיין כתיבה ותפעול ASP.NET תהיה קלה יותר ופשוטה יותר מכמה סיבות:
א. אין צורך בלולאות איחזור נתונים – יש פקדים מקושרים אוטומטיים.
ב. קוד סקריפט צריך יותר פעולות לבצע מה שקוד OOP מלא הכוללת מטפלי אירועים ומחלקות, יכול לבצע.
ג. ASP.NET לא כותבת קוד שרת בתוך אזור כתיבת ה HTML, אלא בקובץ נפרד, המנוהל יחד עם קובץ HTML סטנדרטי.
וזה רק חלק מהסיבות.
והמשך דברי…
פיתוח אוטומטי הוא בד"כ באמת חרב פיפיות כי הגישה הידנית רחבה יותר מגישה אוטומטית, אלא שבמקרה של ASP.NET זה לגמרי לא נכון.
קובץ DATASET היוצר טבלאות נתונים וקבצי XML אוטומטיים מאפשר גישה ידנית יותר רחבה להגדרות, ושימוש מופחת בזיכרון, מכתיבת DATASET ידני.
טבלאות מקושרות אוטומטיות כמו GRIDVIEW מאפשרות אוטומציות כולל קוד אוטומטי מובנה למיון קדימה אחרוה וסינון נתונים, PAGING ועוד, וביחד עם זה מאפשר לי לשלוט על כל חלקיק וחלקים בעיצוב שלו, בנתונים המקושרים שיושבים בתוכו, ובכל חלק וחלק, עד הרמה הכי מפורטת שיש, בקוד יותר קצר מהתייחסות דומה להרצת קוד בלולאה ידנית. לדוגמה, בלולאה ידנית תצטרך להגדיר לכל פקד, שם זיהוי שונה, ותצטרך לבצע פונקציות שמחשבות את שמו של הפקד.
בASP.NET שם הפקד בצד שרת זהה לכל שורות הטבלה, ועל ידי שורת קוד אחת, אני יכול לדעת את שמו המדוייק בצד לקוח של הפקד, ועל ידי שורה אחת אני יכול ללכוד שורה ספציפית, טור ספציפי ופקד מסויים בטבלה, כדי לעבד דווקא אותו ספציפית.
3. VIEWSTATE. ההבנה שלך בפעולת VIEWSTATE היא לקויה.
VIEWSTATE לא עובד כמו שאמרת, הוא לא צריך לעבוד כך. אכן מקבלים כמה פקדי HIDDEN עם מחרוזות לא ברורות, אבל זה הרי לא באמת איכפת לי. וכי מה אכפת לי לראות עוד שורת קוד או אפילו חמש שורות לא מובנות?
אבל, השורה הזאת לא נשלחת לשרת בביצוע postBack בכלל. אין סיבה. מה שנשלח לשרת אלו הפקדים הסטנדרטיים. פקד HIDDEN של VIEWSTATE הוא קריאה בלבד מרגע שהוא בצד לקוח. אם נגיד היו לי שתי תיבות טקסט, ובאחד כתבתי את שמי: אביעד, והשניה ביקשה לדעת את אזור מגורי ורשמתי בה: שומרון, אזי, זה נשלח בPOSTBACK לשרת. כשהדף חוזר עם הפלט מהשרת, הוא חוזר עם ה-VIEWSTATE החדש, ומשכתב אותו לתוך הHIDDEN.
איני חושב שמישהו מלבד מיקרוסופט, מבין לגמרי את השימוש בתגית HIDDEN הזאת ואת משמעות וצורת הכתיבה בתוכה. אבל, בכל אופן, גם לו היתה משוגרת לשרת, לא זאת השורה שתכביד על התעבורה. וכבר אמרתי, שכל מי שלא רוצה להשתמש בVIEWSTATE יכול להגדיר על ידי פקודה אחת בראש הדף, את ביטולה.
מעבר לכך, בו נחשוב מה יותר כבד לשרת:
תגית HIDDEN טקסטואלית לחלוטין אם קצת טקסט לא ברור?
או כחמש עד עשרים לולאות אם משפטי תנאי, כדי לבצע עצמאית את מה שVIEWSTATE מבצעת.
חשוב רגע מה אתה מעדיף. שכל פעם שהדף יבצע POSTBACK הוא ימנע ממשלוח תגית HIDDEN אחת, אבל יבצע קריאה חדשה למסד הנתונים ושליפת נתונים מחודשת, או תגית HIDDEN נוספת, שבזכותה המחשב לא יבצע קריאת נתונים נוספת ממסד הנתונים בPOSTBACK (כי VIEWSTATE שומר גם על טבלאות הנתונים באופן מלא)?
ודרך אגב כמה זוטות:
ASP.NET אינה עושה יותר POSTBACKS, היא עושה זאת רק כשהלקוח רוצה לבצע זאת.
עם מנוע ATLAS (זה AJAX ייחודי) ומנועים כמו magic ajax ו- ajax.net יש ניצול מלא של הייחודיות של ASP.NET גם לAJAX.
PHP לא יכולה להיות OOP מלא, כי שפת OOP חייבת להכיל: מחלקות, הורשה, רב צורתיות, העמסה, בנאים…
בברכה
אביעד
לגבי הסוף, כאן מתבטא חוסר הידע שלך
PHP 5 הפכה לשפת OOP כמעט מלאה. יש הורשה, מחלקות, ממשקים, בנאים וכל השאר (רק העמסה מתודות עוד לא קיים).
לגבי ה-viewstate, אתה סותר את עצמך. מצד אחד אתה אומר שזה רק בלקוח ולא נשלח לשרת, מצד אחר אתה אומר שב-viewstate נשמרים כל המידע של הפקדים, וכך השרת יודע את התכונות השונות של הפקד.
אז אני אגיד לך שזה כן נשלח לשרת משלוש סיבות:
1. אין על ה-input של זה disabled.
2. הדפדפן לא מבין מזה שום דבר (זה מקודד ולא אומר כלום)
3. אם תבדוק את בקשת ה-HTTP תראה שזה כן קיים שם.
ואני לא רואה שום יתרון בזה שהשרת יודע איך הפקד נראה בצד הלקוח, זה לא עניינו.
לגבי אטלס, תסביר לי מה זה AJAX יחודי, פעם ראשונה שאני שומע על זה.
ואאל"ט יש פרוייקט המרה של אטלס ל-CF.
מלבד זאת אתה לא יכול לזקוף את אטלס ממש לזכותו של ASP.NET כי הוא בא באיחור ענקי אחרי script.aculo.us, prototype, dojo toolkit והשאר. שהן בשלות מאוד (בעוד שאטלס רק בגרסאות ה-CTP).
לגבי אובייקט ה-Request, אז בסה"כ הפלטפורמה עושה את ההמרה עבורך, מתכנתים חכמים כמו זהר למשל יודעים לעשות בעזרת שימוש מתקדם בJS את הדברים האלו פשוטים יותר.
לגבי תכנות מונחה אירועים. אני יכול להגיע לך לרמה אפילו מתקדמת יותר של זה בעזרת AJAX ושימוש ב-RoR, רק שבשימוש ב-RoR זה יהיה הרבה יותר פשוט ו-Reusable.
בוא תענה לי על שאלה:
למה אני צריך לדעת את קיומם של פקדים בצד השרת? איך זה עוזר לי?
אם ממילא השימוש היחידי שאני צריך זה המידע שהם מחזיקים, מה שהמשתמש הזין/בחר.
ומי שמתכנת נכון יודע גם להפריד בין הקוד לעיצוב (כבר אמרתי XML ו-XSL? ויש עוד דרכים)
כנראה לא הבנת את כוונתי
אתה יכול להשוות שני סוסים, אבל אתה לא יכול להשוות סוס לכריש.
גם סוס וגם כריש נמצאים בסביבות שונות, עובדים בדרכים שונות וזזים בדרכים שונות.
בדיוק כך גם ASP.NET ו-JSP. לעומת זאת פרל ופייטון למשל תוכל להשוות כי אין עובדות באותן סביבות, באותה דרך וכו'…
יש מבין?
אתה ממשיך למחזר שזה מפליא.
זוטות:
נו… הנה, הוכחת – PHP 5 חסרה תכונה שבלעדיה אין OOP.
כל ספר יסביר לך את זה. חוץ מזה, גם לו היא היתה OOP, זה אינו נושא הדיון שלנו.
ולעניינינו:
אני חש, כי הטענות שלי, לא רק שלא נענות, אלא אתה מנסה ליצור דמגוגיה.
כיצד ומדוע?
אינך מנסה להוכיח שיכולותיה של ASP.NET נחותות, או לא טובות, וגם אינך מצליח להוכיח אפילו שאינן נדרשות.
במקום זאת, כל מילה שאזרוק לאוויר, אתה תנסה לפלפל ולהקשות עליה פרטנית, מבלי שבכלל יהיה במילה הזאת משהו משמעותי.
1. השוואתי מסכת העוברת שני תהליכים – אחד request רגיל ואחד תהליך מונחה אירועים של ASP.NET.
הוכחתי שם כיצד ASP.NET תהיה בשל כך זריזה יותר, ותקצר תהליכים + הפחתת קוד.
אני מסכים שניתן לבנות חלופות בכל שיטה, אבל איפה ההוכחה שלך שזה יהיה יותר יעיל וקצר מASP.NET?
2. הבהרתי כי VIEWSTATE שומר את הנתונים שהזנו לפקדים (לא מאפיינים, אלא נתונים שהשרת הזין ושהלקוח הזין). הסברתי את קיצור זמן ההמתנה והיעילות שבPOSTBACK כזה, שבמקום לגשת שוב ולקרוא נתונים, כבר זוכר אותם עצמאית (זה גם מאובטח יותר).
אתה רק ניסית להמשיך לטעון שוב ושוב שVIEWSTATE עוברת לצד שרת. סבבה, נגיד שאני בור ועם הארץ בשבילך, לא יודע מהחיים שלי בVIEWSTATE והיא אכן עוברת מצד לצד, עדיין עליך להוכיח שזה מאיט, מעכב תהליכים, וכד'.
3. אני הצגתי יתרונות עצומים בעבודה מהירה מול מסדי נתונים בASP.NET, ואתה עדיין לא שללת אף אחד מהם…
בקיצור, הגיע הזמן שלא תנסה להתעקש בזוטות, ותכחיש את דבריי.
לגבי שתי שאלותיך:
ATLAS עובד על תיאוריית AJAX, אלא שהוא מקשר דינאמית בין הפקדים שלו וJS, לשרת ע"י SOAP ו- WEB Services – הוא כותב עצמאית את הXML, הוא חובר בצורה מאובטחת מאוד למסד הנתונים, והוא שולף מאוד מהר את הנתונים. יש עוד דברים רבים בתוכו – עולם ומלואו שטרם הספקתי להכיר וללמוד לעומקם, אבל בעיקרון מיקרוסופט כבר זמן רב מפתחת ועובדת איתו, אלא שעכשיו היא גם מוציאה לאור לכולם.
ATLAS כמו כמה מנועים אחרים מותאמים ספציפית ליכולות ASP.NET דווקא.
לגבי שאלתך על תכנות מונחה אירועים באינטרנט בצד שרת:
זה נכון שלתיבת טקסט פשוטה אין הרבה משמעות, למעט מציאות בה אני רוצה לעצב הכל ולצייר את הדף שלי באופן מוחלט על ידי מסדי נתונים וקוד.
אבל תכנות מונחה אירועים מגיע לשיאו בעבודה עם טבלאות מקושרות, ועם עומסי נתונים.
בטופס ASP רגיל, יש לחצן SUBMIT, או כל צורה אחרת שמבצעת SUBMIT לטופס כולו. אבל, אני בASP.NET לא רוצה לבצע SUBMIT לכולו, אלא רק לרענן שורה מאוד ספציפית במסד הנתונים המקושר לטבלה בה ביצעת את הPOSTBACK.
ASP, PHP ואחרות, בכל מקרה ישלחו את כל הדף לטיפול, אבל בASP.NET היא יודעת להתמקד באירוע הספציפי שגרם, ולבחון את קוד הפרוצדורה הפרטית שלו והמחלקות המקושרות אליה בלבד.
גם בAJAX אמנם אפשר לטפל בחלק מסויים בדף, ואפילו בלי לרענן את הדף בכלל, אבל עדיין הקוד מאוגד יחדיו לכל הפעולות וכל הפקדים שיש בתוך אותה אפליקציה קטנה.
בASP.NET אני יכול להגיע להתייחסות בודדת ונפרדת לכל פקד ופקד, גם אם הוא פקד בתוך פקד בתוך פקד בתוך טבלה מקושרת. עם AJAX הייחודי לה, זה אפילו משתפר.
מהירות ניתן להשוות, השאר לא.
OOP בנוי משלושה חלקים
הורשה, פולימורפיזם, וכמיסה (encapsulation).
לא בהורשה, לא בפולימורפיזם ולא בencapsulation יש את החובה להעמסת פונקציות. בכל ספר על C#/CPP ו-JAVA תראה את זה נכון, כי זה פיצ'רים של השפות. אבל ברובי ו-PHP למשל זה לא קיים ורובי היא שפת OOP מלאה.
אז יפה ATLAS עובד עם Web Service,אבל איפה ה-reusable של זה? אם תרצה לבצע קוד מסויים מעמודים שונים, פעם אחת דרך פקד ופעם אחרת דרך אלטס, אז בסופו של דבר תצטרך לכתוב את הקוד שוב, אפילו אם את הלוגיקה תכתוב בצד (במחלקה/מתודה נפרדת) עדיין תצטרך לכתוב קוד שיבצע את הקריאה לזה.
לעומת זאת נגיד עם ROR אני אוכל ע"י כתיבת ה-controller בלבד לקרוא למתודה שלו גם בעזרת AJAX וגם בדרך הרגילה (של טופס) ובכל פעם להחזיר בפורמט שונה וזאת רק ע"י שינוי header של HTTP בלבד. כאן כתבתי את הקוד פעם אחת, והקריאה אליו מתבצעת אוטומטית, בלי שאני אצטרך לעשות זאת בעצמי כל פעם.
איני מנסה להוכיח ש-ASP.NET היא גרועה, כי היא לא, יש לה יתרונות אבל הם לא בהכרח אלה שאתה הצגת, וכן, הן לא סיבות לעבור לפתח ב-ASP.NET כי הן מוטעות בחלקן.
גם מהירות לא.
תשים סוס וכריש בתוך מים עמוקים (שמכסים את כל הרגליים של הסוס)
מן הסתם שהכריש יזוז יותר מהר מהסוס, כי זאת הסביבה הטבעית שלו, הוא בנוי עבורה.
הסוס עדיין יזוז אבל לאט יותר. לעומת זאת אם תוציא את הכריש מהמים ותשים אותו בשדה, הוא בקושי יזוז (אם לא ימות) לעומת הסוס שידהר.
מה שאני בעצם מנסה לומר שJSP ו-ASP.NET הן דומות רק ברעיון הגלובלי, אבל סביבות ההרצה שלהן שונות, אחת מותאמת יותר לכמה פלטפורמות והשנייה רק לפלטפורמה אחת ולכן יש הבדל בביצועים ביניהן כי הרבה יותר פשוט לבצע אופטימיזציות ולשמור על אחידות פעולה כשעובדים רק על פלטפורמה אחת.
ניר, אולי תהיה אמיתי עבור הגולשים?
זה ממש זילזול, תסלח לי. אבבל אני מצפה שאם אני מבין לך דוגמאות, הוכחות, השוואות, אתה תבוא ותכחיש אותן או תוכיח כנגדן.
לא עשית זאת.
אני מתחיל לחוש שאתה מחזיק מעצמך כל כך, שאתה מאמין שדי לך באמיר כמו זאת:
"הן לא סיבות לעבור לפתח ב-ASP.NET כי הן מוטעות בחלקן".
בלי שאתה אפילו מוכיח א הסיסמא הזאת שבחרת בה.
ודרך אגב, ATLAS מותאם לפקדים הסטנדרטיים. אפשר לעבוד ברוב הפקדים במקביל, וASP.NET דווקא מגבירה את יכולת השימושיות של אובייקט.
אני קורא כאן לכל אדם הקורא את הדיון הזה, להבהיר לניר היקר, שטענותיו אינן שוות מאומה בלי הוכחות.
תירוץ מעט עגום
קודם כל, הבדיקה בוצעה שרת עם J2EE על לינוקס מול WIN SERVER 203 עם IIS6 וNET 2.
אבל מעבר לכך, התירוץ שלך נשמע קצת מוזר ועגום. אם יש לי שרת מיקרוסופט, דבר שכיום בשרתים בחו"ל עולה בדיוק כמו שרת לינוקס, וASP.NET יעילה עליו כל כך, מדוע לי להשתמש בשיטה אחרת רק בגלל שהיא אולי איטית אבל רצה על יותר פלטפורמות שאינן משנות לי?
ואני מרגיש שאתה מתייחס רק לחלקים
ממה שאני כותב, כי אני כן מגיב לך וטוען דברים מוכחים. למשל על ה-Reusable קוד של RoR+AJAX כנגד EOP+Atlas.
על כך שאפשר לבצע בקלות רבה עם AJAX ו-RoR את התכנות מובנה אובייקטים ואפילו בצורה פשוטה וחלקה יותר מב-ASP.NET.
על כך שאמרת ש-PHP היא לא OOP ואני הוכחתי שהיא כן.
אתה אומר: "אני יכול לבחור אם לקבל אותו ולבצע עצמאית REQUEST, או לקבל אותו כבר ארוז ומוכן, כINTEGER או כסוגו המקורי, בתוך הפקד, מוכן להמשך עיבוד מתקדם"
אבל שאני שולח SQL למסד (אפילו בשימוש באובייקט command אין חשיבות לסוג הטיפוס שאני שם כנתון, הוא יודע לטפל בזה אוטומטית) אז אין חשיבות לסוג הנתון אצלי באפליקציה עבור הSQL, כי ב-SQL אני אצטרך להגדיר אותו מחדש בתור מס', תאריך וכו'.
"JSP ו- ASP.NET פותחו על אותו רעיון, רק ש- ASP.NET הרחיבה יותר ושכללה יותר את עיקרון העבודה באינטרנט, והוסיפה יותר עבודה מונחית אירועים."
האם בדקת את זה קודם? אמנם ל-JSP אין את היכולת הזו בילט אין ולדעתי זה עדיף. יש הרבה פרוייקטים צד שלישי שהם Open source שמאפשרים לתכנת ב-EOP.
מה היתרון בזה? שהמתכנת בוחר את דרך הפיתוח שנוחה עבורו ולא הפלטפורמה.
אמרת לזוהר: "אתה יכול להסכים עם ניר מהיום ועד מחר – זה קטנוני ולא בוגר"
אם הוא החליט להסכים איתי, סימן שיש לו סיבה מסויימת, זה לא אומר שהוא קטנוני ולא בוגר.
יש כל מיני סוגים של עיצובי אפליקציות, ביניהן MVC, וכיוון ש-MVC זה מעין רעיון לעיצוב אפליקציה אז ניתן לממש אוו בדרכים שונות.
למשל הדפסת המודל לתוך קובץ XML. ואז ה-VIEW הוא קובץ XSL שמפרמט את ה-XML. כך שיש חלוקה ברורה, המודל זה XML, ה-VIEW זה קובץ ה-XSL וה-controller זה קוד PHP/ASP/וואטאבר.
אז ראית איך הפרדתי בין קוד לתצוגה בשימוש חכם בכלים הנכונים (וסטנדרטיים)?
אסור שהראש יהיה מקובע.
XML Scheme כפי שאני מבין נועד כדי לתאר מבנה של קובץ XML בדומה ל-DTD.
"פקדי NET פועלים אצלי מאוד מהר" אצלך במחשב האישי (=משתמש אחד)?, אצלך בשרת של ה-production? עם כמה משתמשים בו זמנית?
המשך
"כי היא מתאימה מאוד לתיאורייה החדשה הקרויה WEB2 ותוכננו עבורה שלושה מנועי AJAX ייחודיים לה, כולם חינמיים, וביניהם מנוע ATLAS המאובטח והמהפכני של מיקרוסופט."
WEB 2.0 זה שם כללי לאפליקציות רשת שנועדו לעבוד באופן כזה של שיתוף תוכן בין הגולשים (עיין ערך דלישס או פליקר). אין שום קשר בין זה לתכנות, זה האופן שבו התוכן באתר נוצר. לגבי החלק ה-AJAXי. כבר אמרתי שATLAS הגיע באיחור לשוק, אחרי שספריות גדולות ממנה ובשלות ממנה כבר קיימות בשוק, אלו שעוסקות בעיקר בצד הלקוח הן prototype, dojo-toolkit ו-script.aculo.us (שבנוייה על prototype) והן הפופולריות ביותר, מלבדן יש עוד עשרות פריימוורקים ל-JS ברחבי הרשת.
מבחינת צד השרת, ישנם גם עשרות פריימוורקים לכל טכנולוגיה לא מתה שמשתמשים בה.
ל-PHP תוכל למשל למצוא את SAJAX ועבור JSP תמצא את DWR שנתמכת ע"י IBM וחברות גדולות אחרות. אגב, DWR נחשבת להרבה יותר בשלה, מפותחת וניתן לשלב אותה יחד עם פריימוורקים נחשבים אחרים כמו Spring, Struts, Hibernate שמיועדים לשימושים שונים. וכן תמצא חבילות שמספקת לך קומפוננטות מוכנות עבור שימוש שוטף בפקדים שדורשים AJAX, כמו רשימות מקושרות.
וכן לא נשכח את GWT של גוגל שיצא בחודש מאי וסחף אחריו הרבה מתכנתים (מעל 50 קומפוננטות הוכנו כבר עבור GWT!) וכן את האינטגרציה שאפשרו לעשות בין GWT ל-JSF וככה להפוך אותו לדינמי אף יותר.
"כי ASP.NET עוברת הידור קוד מלא, דבר ההופך אותה למהירה הרבה יותר מכל תקן או שיטה אחרת."
ASP.NET לא עוברת הידור קוד מלא, ההידור היחידי שנעשה לה זה ל-bytecode כפי שכבר נאמר פה בשרשור.
"עושים סוף לשימוש בסקיפרטים מוגבלים."
סקריפטים זה הכל חוץ ממוגבל, זה למה הם הומצאו. כמו כן שפות סקריפטים של היום כמו PHP, רובי, פייטון הן OOPיות וכן גם JS וגם VBS (אמנם לא מלאות).
כמו כן לאחרונה יש גל מסויים של יצירת מנועים שיודעים לשלב שפות סקריפטים יחד עם שפה עילית כמו JAVA.
"כי היא מדברת באופן מהיר יותר, מאובטח יותר ושוטף יותר עם כל סוגי מסדי הנתונים, ועם קבצי XML ו- XML SCHEMA."
תוכיח.
JDBC 4 וכל native connection מגיע לרמה מאוד גבוהה של מהירות עם מסדי נתונים.
ולא נשכח שיש כמה וכמה מסדים JAVAיים שהם יכולים להיות embedded בתוך התוכנית ואז הגישה אליהם אפילו יותר מהירה או שיש להם אינטגרציה מלאה עם JAVA. כמו למשל HSQLDB, Derby, PostgresSQL.
המשך
"כי סוף כל סוף מיקרוסופט מחלקת תוכנה מתקדמת בחינם (Visual Studio 2005) באתר שלה, תוכנה מאוד מתקדמת, המקצרת בשליש פיתוח אתרים, ומאפשרת לנהל קוד בצורה מעולה, והכל בחינם."
ה-VS המלא הוא לא בחינם וצריך רישיון בשבילו. לעומת זאת ל-JAVA ו-PHP יש הרבה מאוד סביבות חינמיות (וחלקן גם Open sources) ומעולות לעבודה איתם, חלקן גם משלבות אינטגרציה מלאה עם מסדי נתונים, פלאגאינים (ויש אלפים) והכי חשוב, עובדות על מגוון פלטפורמות.
"כי היא עושה סוף לצורך בלולאות קשות ומסובכות להצגת לולאת רשומות נתונים, או לבדיקת מידע בטופס. הכל נעשה אוטומטית על ידי פקדים מובנים בעושים אימות ופקדים מובנים שמתחברים לאובייקטי נתונים ויודעים לשלוף ולסדר היטב את הנתונים כמו בלולאה. בנוסף, ניתן לשלוט פרטנית על עיצוב השורות של הטבלה."
תסתכל על גישת ה-XML ו-XSL שלי. הרבה יותר נקי לדעתי משימוש בפקדים של פלטפורמה מסוימת (כמו שהבנתי היו אי תאימויות בין ASP.NET 1.1 ל-2 בפקדים).
"כי היא עושה יותר סדר בקוד, שומרת HTML ו- קוד לוגי בשני קבצים נפרדים לגמרי, מאפשרת אריזת קוד לשימוש קבוע, כאובייקט מושלם, מאפשרת ליצור קבצים שלימים של XML כדי לשמור על מידע ממסד הנתונים וכו'. כמו כן, ניתן לשלוט דרכה באופן מוחלט על IIS."
שוב ראה את גישת ה-XML ו-XSL שתיארתי קודם. והוכחתי ש-ASP.NET ופקדיה הם לא מספיק reusable לעומת RoR (וגם לעומת בנייה נכונה של אפליקציות ב-PHP ו-JSP).
"כי ההתחדשות שלה דינאמית מאוד, הן על ידי מיקרוסופט עצמה, והן על ידי אגודות תוכנה המפתחות עליה אפליקציות. כל חודש ניתן למצוא חידושים מרעננים."
אם זה מה שאתה אומר על ASP.NET, אז זה אפילו יותר נכון עבור PHP ו-JSP, כל כמה ימים תוכל למצוא חידושים של צד שלישי לל-PHP ו-JSP
מספיק שתעיין ב-TheServerSide.com וב-digg.com/programming.
וזה הכי נכון לגבי PHP שלא עומדת מאחוריה רק חברה, אלא גם קהילת מתכנתים מבין הגדולות בעולם, שכל הזמן מפתחים לה הרחבות ואפילו יותר טוב ממה ש-MS עושים כי לקוב זה בקוד פתוח, וכך אתה יכול ללמוד איך עשו את הדבר ולא להשתמש בקופסה שחורה.
דוגמא: עשו פורטינג למנוע שנקרא כהרחבה ל-PHP וזה מהימים האחרונים.
בפוסט ארוך זה הראתי איך ASP.NET עדיין לא בשלה מספיק לעומת פלטפורמות אחרות שנמצאות זמן ארוך יותר ממנה, ונמצאות בשימוש רב יותר ממנה בשוק הבין לאומי.
כמו כן…
פרוייקטים בקוד פתוח שנכתבו עבור JAVA הם נמצאים בשלבים של המרה ל-ASP.NET כדי לאפשר את השימוש שלהם גם ב-ASP.NET (כמובן שרוב הפרוייקטים האלו מומרים ע"י אנשים שמשתמשים ב-mono, כי הם מאמינים בקוד פתוח)
דוגמא לפרוייקטים כאלה:
NUnit שזה הפרויקט המקביל JUnit.
NHibernate שמקביל ל-Hibernate המקורי.
log4net שזה הפרוייקט המקביל ל-log4j.
בסה"כ אנשים שמבינים דבר, רואים ש-ASP.NET עדיין לא בשלה כמו J2EE ולכן ממירים פרוייקטים ל-ASP.NET, וש-J2EE הרבה יותר גמישה למתכנת מאשר ASP.NET.
וכן, יש הרבה יותר חומר כתוב וגוראים ל-J2EE מאשר ל-ASP.NET.