WEB API
שאלה
תשובות
-
אהלן,
שאלות כאלה אי אפשר לדעתי לענות בפורום :-)
אלו שאלות שקשורות לאפיון וארכיטקטורה של אפליקציה וכל גישה אליהם מחייבת מחקר מעמיק והכרה מלאה של המערכת הקיימת שלכם, המשאבים שעומדים בפניכם (משאבים כוללים כסף אבל גם ידע וזמן למשל), הצרכים הנוכחייים ובעיקר הערכה של הצרכים העתידיים. תכנון נכון הוא לא זה שנותן פתרון כרגע אלא זה שגמיש מספיק לתת פתרון לטווח ארוך ככל הניתן תוך עמידה במגבלות הנוכחיים. צריך תמיד לזכור שמה שמתאים לאחד לא בטוח יהיה מה שמתאים לאחר. לאותה שאלה אני אתן תשובה שונה לחלוטין אצל 2 לקוחות שונים שלי.
מה שאנחנו יכולים לעשות בפורום זה לתרום רעיונות והצעות אפשריות, לתת נקודות בהן כשאי להתחשב בקבלת ההחלטה ולקיים דיון ספציפי בנקודות. אני אנסה לתת כמה נקודות דיון חשובות שאמורות לעזור לך להגיע להחלטה שמתאימה לך
>> אני מבינה שאת הclient יוצרים בפרויקט נפרד
אם בוחרים בארכיטקטורה של שכבת שירות (API) אז כמובן שזה הרעיון. אין קשר בין אפליקציית הלקוח לאפליקציית השירות.
לא לכל מצב נכון לבחור את אותה ארכיטקטורה
>> אני מבינה שאת הclient יוצרים בפרויקט נפרד, איזה סוג של פרויקט הוא אמור להיות? MVC? סתם webApp?
שאלה מכוונת חשובה:
למה בכלל החלטתם לעבוד עם API?בדרך כלל ההפרדה לשכבות של אפליקציות לקוח ואפליקציות שירות נועדה לתת לנו גמישות וזה בדרך רעיון טוב. למשל אם אנחנו מפתחים אפליקציה אחת בלבד בכל החיים שלנו ויודעים שלא יהיה כלום שונה בעתיד אז למה לבצע הפרדה? ההפרדה לא תפיק לנו הרבה אלא רק יוצרת מורכבות בניהול ותכנון. אבל אם יש לנו 1000 אפליקציות שונות שצריכות לבצע את אותה פעולה בסיסית (למשל ניתוח מידע מהשרת SQL והחזרת ערך מסוכם כלשהו) אז למה לבצע את הפעולה 1000 פעמים בכל אפלקציה. המשמעות של חלוקה לשכבת שירות ושככבת אפליקציות מתחילה להיות מאוד חכמה מכיוון שאפשר לנהל אפליקצית שירות אחת בלבד וכל אפליקציית לקוח תפנה אליה. יותר מכך אם האפליקציות שלנו הן שונות ומגוונות מאוד, למשל יש אפליקציה שנועדה לטלפונים ואפליקציה שנועדה לדפדפנים ואפליקציה שנועדה לשירותים שעובדים מאחורי הקלעים, ויש לנו אפליקציות למערכות הפעלה שונות... כאן הכוח של אפליקציית שירות ממומש בצורה מלאה כבר :-)
אחרי שהבנו את למה בכלל אנחנו בוחרים לעבוד בארכיטקטורה של שכבת שירות, אנחנו יכולים לחשוב איזה אפליקציית שירות אנחנו צריכים. MVC היא טכנולוגייה נוחה וקלה מאוד למימוש אבל היא מאפשרת ליצור אפליקצייה WEB (כפי שהזכרת) ומוגבלת ביכולות שלה. למשל MVC מוגבל בפרוטוקולים בהם נוכל לתקשר איתה. אפשרות יותר גמישה לאפליקציית שירות היא שימוש באפליקציית WCF.
אני מאוד ממליץ לפני שמקבלים את ההחלטה לבצע חיפוש ולקרוא בלוגים שמבציעם השוואה בין 2 האפשרויות הנ"ל. כדאי לחפש בגוגל:
wcf vs web api
את תמצאי אלפי מאמרים טובים בנושא :-)* כמובן שיש עוד אפשראויות אבל למפתח C# הייתי אומר שאלו הכיוונים הכלליים הנפוצים ביותר.
>> זה משנה בכלל???
זה משנה מאוד!
תכנון נכון היום יכול להיות כל ההבדל של הצלחת העסק מחר.
בחירה שלא מתאימה לכם יכולה להוביל לכך שבעתיד יהיה צורך לפתח מודולים נוספים מיותרים. תכנון נכון יכול להוביל לחסכון בזמן הפיתוח, יותר חשוב מכך (מכיוון שפיתוח ראשוני נעשה פעם אחת), הוא מוביל לחסכון ניכר בזמן הניהול והתחזוקה וכמובן בהוצאות על התחזוקה של האפליקציה היום ובעתיד, ולא פחות חשוב לזכור שהוא משפיע על משאבים ישירים של הפעלת השירותים (חלוקה נכונה לשכבות יכולה להוביל לחלוקה של משאבים נכונה שיכולה להוביל גם לחיסכון בהוצאות חומרה).* לסיכום, כל עוד אין מידע נוסף מעמיק הייתי מציע לבדוק אפשרות של שימוש ב WCF ו MVC כפשרויות ברירת מחדל שמתאימות לרוב המצבים עבור אפליקצית API.
Ronen Ariely
[Personal Site] [Blog] [Facebook] [Linkedin]- נערך על-ידי pituachMVP, Moderator יום רביעי 10 אוגוסט 2016 15:32
- סומן כתשובה על-ידי ssf.ssf יום חמישי 11 אוגוסט 2016 06:49
כל התגובות
-
אהלן,
שאלות כאלה אי אפשר לדעתי לענות בפורום :-)
אלו שאלות שקשורות לאפיון וארכיטקטורה של אפליקציה וכל גישה אליהם מחייבת מחקר מעמיק והכרה מלאה של המערכת הקיימת שלכם, המשאבים שעומדים בפניכם (משאבים כוללים כסף אבל גם ידע וזמן למשל), הצרכים הנוכחייים ובעיקר הערכה של הצרכים העתידיים. תכנון נכון הוא לא זה שנותן פתרון כרגע אלא זה שגמיש מספיק לתת פתרון לטווח ארוך ככל הניתן תוך עמידה במגבלות הנוכחיים. צריך תמיד לזכור שמה שמתאים לאחד לא בטוח יהיה מה שמתאים לאחר. לאותה שאלה אני אתן תשובה שונה לחלוטין אצל 2 לקוחות שונים שלי.
מה שאנחנו יכולים לעשות בפורום זה לתרום רעיונות והצעות אפשריות, לתת נקודות בהן כשאי להתחשב בקבלת ההחלטה ולקיים דיון ספציפי בנקודות. אני אנסה לתת כמה נקודות דיון חשובות שאמורות לעזור לך להגיע להחלטה שמתאימה לך
>> אני מבינה שאת הclient יוצרים בפרויקט נפרד
אם בוחרים בארכיטקטורה של שכבת שירות (API) אז כמובן שזה הרעיון. אין קשר בין אפליקציית הלקוח לאפליקציית השירות.
לא לכל מצב נכון לבחור את אותה ארכיטקטורה
>> אני מבינה שאת הclient יוצרים בפרויקט נפרד, איזה סוג של פרויקט הוא אמור להיות? MVC? סתם webApp?
שאלה מכוונת חשובה:
למה בכלל החלטתם לעבוד עם API?בדרך כלל ההפרדה לשכבות של אפליקציות לקוח ואפליקציות שירות נועדה לתת לנו גמישות וזה בדרך רעיון טוב. למשל אם אנחנו מפתחים אפליקציה אחת בלבד בכל החיים שלנו ויודעים שלא יהיה כלום שונה בעתיד אז למה לבצע הפרדה? ההפרדה לא תפיק לנו הרבה אלא רק יוצרת מורכבות בניהול ותכנון. אבל אם יש לנו 1000 אפליקציות שונות שצריכות לבצע את אותה פעולה בסיסית (למשל ניתוח מידע מהשרת SQL והחזרת ערך מסוכם כלשהו) אז למה לבצע את הפעולה 1000 פעמים בכל אפלקציה. המשמעות של חלוקה לשכבת שירות ושככבת אפליקציות מתחילה להיות מאוד חכמה מכיוון שאפשר לנהל אפליקצית שירות אחת בלבד וכל אפליקציית לקוח תפנה אליה. יותר מכך אם האפליקציות שלנו הן שונות ומגוונות מאוד, למשל יש אפליקציה שנועדה לטלפונים ואפליקציה שנועדה לדפדפנים ואפליקציה שנועדה לשירותים שעובדים מאחורי הקלעים, ויש לנו אפליקציות למערכות הפעלה שונות... כאן הכוח של אפליקציית שירות ממומש בצורה מלאה כבר :-)
אחרי שהבנו את למה בכלל אנחנו בוחרים לעבוד בארכיטקטורה של שכבת שירות, אנחנו יכולים לחשוב איזה אפליקציית שירות אנחנו צריכים. MVC היא טכנולוגייה נוחה וקלה מאוד למימוש אבל היא מאפשרת ליצור אפליקצייה WEB (כפי שהזכרת) ומוגבלת ביכולות שלה. למשל MVC מוגבל בפרוטוקולים בהם נוכל לתקשר איתה. אפשרות יותר גמישה לאפליקציית שירות היא שימוש באפליקציית WCF.
אני מאוד ממליץ לפני שמקבלים את ההחלטה לבצע חיפוש ולקרוא בלוגים שמבציעם השוואה בין 2 האפשרויות הנ"ל. כדאי לחפש בגוגל:
wcf vs web api
את תמצאי אלפי מאמרים טובים בנושא :-)* כמובן שיש עוד אפשראויות אבל למפתח C# הייתי אומר שאלו הכיוונים הכלליים הנפוצים ביותר.
>> זה משנה בכלל???
זה משנה מאוד!
תכנון נכון היום יכול להיות כל ההבדל של הצלחת העסק מחר.
בחירה שלא מתאימה לכם יכולה להוביל לכך שבעתיד יהיה צורך לפתח מודולים נוספים מיותרים. תכנון נכון יכול להוביל לחסכון בזמן הפיתוח, יותר חשוב מכך (מכיוון שפיתוח ראשוני נעשה פעם אחת), הוא מוביל לחסכון ניכר בזמן הניהול והתחזוקה וכמובן בהוצאות על התחזוקה של האפליקציה היום ובעתיד, ולא פחות חשוב לזכור שהוא משפיע על משאבים ישירים של הפעלת השירותים (חלוקה נכונה לשכבות יכולה להוביל לחלוקה של משאבים נכונה שיכולה להוביל גם לחיסכון בהוצאות חומרה).* לסיכום, כל עוד אין מידע נוסף מעמיק הייתי מציע לבדוק אפשרות של שימוש ב WCF ו MVC כפשרויות ברירת מחדל שמתאימות לרוב המצבים עבור אפליקצית API.
Ronen Ariely
[Personal Site] [Blog] [Facebook] [Linkedin]- נערך על-ידי pituachMVP, Moderator יום רביעי 10 אוגוסט 2016 15:32
- סומן כתשובה על-ידי ssf.ssf יום חמישי 11 אוגוסט 2016 06:49
