בחירת הטכנולוגיה הנכונה לבניית שכבת השירות ב- .NET

בעת תכנון שכבת השירות ביישומים שלך בחירת הטכנולוגיה לשימוש בשכבת השירות תלויה בגורמים רבים. במאמר זה אציג דיון מתי ואיך תוכלו להחליט לבחור את הטכנולוגיה המתאימה ליישום שכבת השירות בעת תכנון יישומים ב- .Net.

שני מתמודדים בולטים שיש לך בעת תכנון שכבת השירות ב- .Net הם WCF ו- Web API. WCF היא פלטפורמת פיתוח עבור SOA - היא מספקת תכונות רבות ותומכת בפרוטוקולי תחבורה רבים ושונים. בעוד ש- WCF מהווה מסגרת אחידה לבניית יישומים מוכווני שירותים, Web API הוא חלופה קלה לבניית שירותים RESTful שניתן לצרוך על ידי לקוחות רבים ושונים. שירותים RESTful משתמשים ב- HTTP בסיסי והם פשוטים עם מטען נמוך בהרבה בהשוואה לשירותי SOAP. אתה יכול להשתמש ב- WebHttpBinding ב- WCF כדי לבנות שירותים שאינם מסוג SOAP RESTful באמצעות HTTP. WCF הוא הרבה יותר תכליתי במובן זה שהוא יכול לתמוך בפרוטוקולי תחבורה רבים - HTTP, TCP וכו '. אתה יכול למנף WCF לבניית שירותים מאובטחים, אמינים ועסקיים שיכולים לתמוך בהודעות, תקשורת דופלקס וערוצי תחבורה מהירים כמו TCP ,צינורות בשם או UDP.

אם אתה צריך לבנות שירותים קלים וממוקדי משאבים באמצעות HTTP שיכולים למנף את התכונות המלאות של פרוטוקול HTTP, להשתמש בגרסאות, בקרת מטמון לדפדפנים ובמקביל באמצעות Etags, Web API הוא בחירה טובה. עליך לבחור Web API על פני WCF בשכבת השירות שלך כאשר תרצה לחשוף את השירותים שלך למגוון רחב של לקוחות, כלומר, דפדפני אינטרנט, מוביילים, טאבלטים וכו '. ה- API של ה- Web הוא קל משקל ומתאים היטב למכשירים מוגבלים. רוחב פס כמו טלפונים חכמים. אחת האילוצים העיקריים שעמדו בפני בעת השימוש ב- WCF היא התצורה הנרחבת שלה - Web API הוא הרבה יותר פשוט וקל לשימוש. אני מודה ש- WCF הוא הרבה יותר תכליתי בהשוואה ל- Web API, אך אם אינך זקוק לתכונות ש- WCF מספק וכל מה שאתה צריך זה רק שירותים RESTful באמצעות HTTP,תמיד הייתי מעדיף Web API מכיוון שהוא קל משקל ופשוט לשימוש.

ברצוני להציג דיון גם על ההבדלים בין Web API ל- ASP.Net MVC מכיוון שקיימות תפיסות מוטעות מסוימות מתי לבחור אחד על השני. הבחירה בין ASP.Net MVC ל- Web API תלויה בגורמים רבים. ישנם שיקולים מסוימים שתצטרך לזכור לפני שתחליט להשתמש באחד מהם.

שים לב כי Web API משתמש בפעלים HTTP ומכאן מיפוי מבוסס פעלים HTTP לשיטות מיפוי למסלולים בהתאמה. לא יכולות להיות לך שיטות עמוסות לאותו פועל HTTP עבור מסלול מסוים. עליך להיות מודע למגבלת התכנון הזו (אם כי ניתן להשיג דרכים לעקיפת הבעיה) בעת בחירה בין ASP.Net MVC ל- Web API. בניגוד ל- ASP.Net MVC, Web API משתמש בניתוב מבוסס על פעלים HTTP ולא URI המכילים פעולות. אז אתה יכול להשתמש ב- Web API כדי לכתוב שירותי RESTful שיכולים למנף את פרוטוקול HTTP - אתה יכול לעצב שירותים שקל יותר לבדוק ולתחזק. ניתוב ב- API של האינטרנט הוא הרבה יותר פשוט ותוכל למנף בצורה חלקה משא ומתן לתוכן. מודל הניתוב ב- ASP.Net MVC כולל פעולות ב- URI.

נקודה נוספת שתרצה לשקול היא האם ברצונך שהפונקציונליות שלך תחשף ליישום ספציפי או שהפונקציונליות צריכה להיות כללית. אם ברצונך לחשוף את שירותיך הספציפיים ליישום אחד בלבד, תרצה להשתמש ב- ASP.Net MVC - הבקר ביישום MVC ASP.Net הוא ספציפי ליישום. נהפוך הוא, היית רוצה גישה של Web API אם הצרכים העסקיים שלך דורשים ממך לחשוף את הפונקציונליות באופן כללי. אני מעדיף להשתמש בגישת ה- Web API אם הפונקציונליות יותר ממוקדת נתונים ובגישה ASP.Net MVC אם הפונקציונליות יותר ממוקדת בממשק המשתמש.

עליך להשתמש ב- Web API דרך ASP.Net MVC אם תרצה שהבקר שלך יחזיר נתונים במספר פורמטים כמו, JSON, XML וכו '. כמו כן, ציון פורמט הנתונים ב- API API הוא פשוט וקל להגדרה. Web API גם ציון על ASP.Net MVC ביכולתו להיות אירוח עצמי (בדומה ל- WCF). תצטרך בקרי ASP.Net MVC להתארח באותו שרת אינטרנט שבו היישום התארח מכיוון שבקרי ASP.Net MVC הם חלק מאותו יישום. להפך, אתה יכול לארח את בקרי ה- Web API שלך גם מחוץ ל- IIS - אתה יכול לארח אותו במארח מותאם אישית קל משקל ולאפשר את צריכת השירות על ידי לקוחות רבים ושונים.