ארכיון תגיות: ASP.NET Core

וולידציה פשוטה ב-ASP.NET Core Web Api

איך עושים וולידציה ב-ASP.NET Core WebApi ?

  • עבור כל אלמנט במודל שנרצה לבדוק – נוסיף Data Annonations על תוכן הוולידציה.
  • בפונקציה עצמה, נפעיל מתודה שבודקת האם המודל עבר וולידציה.

 

דוגמא למודלים עם ולידציה :

public class JustTry {
 
 [Range(15,34)]
 public int Id { get; set; }

 [MaxLength(30)]
 public string Koko { get; set; }


}

------------- OTHER MODEL WITH DATA ANNONATIONS --------
[Required]
 [StringLength(100)]
 public string Name { get; set; }

 [Required]
 [EmailAddress]
 public string Email { get; set; }

 [Required]
 [Phone]
 public string Phone { get; set; }

 [Required]
 [Url]
 public string Site { get; set; }

 [Range(0,130)]
 public int? Age { get; set; }

 [Required]
 [StringLength(500)]
 public string Message { get; set; }

מימוש פונקציה עם ולידציה :

[HttpPost]
 public IActionResult Post([FromBody]JustTry jj)
 {
 if (!ModelState.IsValid)
 {
 return BadRequest();
 }

 
 ... 
 ... Your Code here to save etc.etc. ...
 ...
 ...

 return Created("Get",jj);
 }

דוקומנטציה – נמצאת בקישור הזה – https://docs.microsoft.com/en-us/aspnet/core/mvc/models/validation .

והמחשה לשילוב עם אנגולר בקישור הזה – http://www.carlrippon.com/?p=720.

 

החזרת Http Response שונים באמצעות Asp.net core web api

בפוסט הזה אדגים כמה צורות להחזיר http response מקונטרולר של asp.net web api.  ועל הדרך נראה גם את הצורות הבסיסיות לכל הפעולות של CRUD.

הערה : לא תמיד אני מציג את הפונקציה במלואה, אז תתאימו את סוג המשתנה שמחזירה הפונקציה אל הדוגמא.

דוגמא 1 – להחזיר קוד Http

החזרת תשובה באמצעות אובייקט HttpResponseMessgae

return new HttpResponseMessage(HttpStatusCode.Created)

זה יחזיר תשובה 200 – כלומר "הכל תקין".

כדי להחזיר תשובה 400 באותו אובייקט , נקליד כך

return HttpResponseMessage(HttpResponseCode.BadRequest);

מתי משתמשים בזה ? 

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

הדוגמא הבאה משתמשת בפועל http post :

 [HttpPost("momo")]
 public HttpResponseMessage Moko([FromBody]Post post)
 {
 try
 {
 
 this._appContext.Posts.Add(post);
 if (this._appContext.SaveChanges() > 0 )
 {
 return new HttpResponseMessage(System.Net.HttpStatusCode.Created);
 } else
 {
 return new HttpResponseMessage(System.Net.HttpStatusCode.BadRequest);
 }
 

 } catch(Exception e)
 {
 return new HttpResponseMessage(System.Net.HttpStatusCode.BadRequest);
 }
 
 }

דוגמא 2 – להחזיר קוד Http עם פונקציות קיצור

בשתי המקרים הקודמים היינו צריכים להגדיר את הפונקציה שתחזיר HttpResponseMessage אך לאובייקטים האלו יש פונקציות קיצור.

בדוגמא הזו הפונקציה מחזירה "כרגיל" IActionResult .

פונקציית קיצור להחזרת תשובה תקינה – -200:

return Ok("everything fine");

פונקציית קיצור להחזרת תשובה לא תקינה 400 :

return NotFound("your requested item didnt found in db");

כמובן שאת המחרוזת בתשובה אפשר לרשום כפי שרוצים.

 

דוגמא 3  – להחזיר מידע בתוך התשובה, באמצעות הפועל Http Get :

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

כמובן שהפריימוורק Asp.net יצמיד לזה קוד 200 ויחזיר את הרשימה בתור מערך JSON.

[HttpGet]
public IEnumerable<MyObj> GetAll() {
return _context.MyObj.ToList();
}

יש אפשרות כמובן גם להחזיר אובייקט מידע בודד (ולא רשימה של אובייקטים רבים).

להלן דוגמא :

[HttpGet("{id}", Name = "GetById")]
public IActionResult GetById(long id)
{
 var item = _context.MyItems.FirstOrDefault(p => p.Id == id);
 if (item == null)
 {
 return NotFound();
 }
 return new ObjectResult(item);
}

במקרה זה החזרנו תשובה תקינה אם הכל נמצא תקין.

ותשובת שגיאה – אם לא נמצא.

דוגמא 4 – לקבל נתונים גם מה-URL וגם מה-BODY – פעולת Update באמצעות הפועל Http Put

בפונקציה הבאה, אנחנו מקבלים 2 נתונים, אחד פרימטיבי – דרך ה-url, והשני מגיע כאובייקט בתוך ה-body  של הבקשה.

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

שימו לב שזוהי קריאת PUT , כלומר במידה ומנסים אותה באמצעות PostMan למשל, אז צריך להגדיר את הקריאה כ-PUT.

[HttpPut("update/{id}")]
 public HttpResponseMessage Update([FromRoute] int id, [FromBody]Post post)
 {
 try
 {

 Post po = _appContext.Posts.FirstOrDefault(x => x.Id == id);
 if (po == null)
 {
 return new HttpResponseMessage(System.Net.HttpStatusCode.NotFound);
 }
 else
 {
 po.Title = post.Title;
 po.Content = post.Content;
 if(_appContext.SaveChanges() > 0 )
 {
 return new HttpResponseMessage(System.Net.HttpStatusCode.OK);
 } else
 {
 return new HttpResponseMessage(System.Net.HttpStatusCode.BadRequest);

 }

 }


 }
 catch (Exception e)
 {
 return new HttpResponseMessage(System.Net.HttpStatusCode.BadRequest);
 }

 }

ישנה אפשרות נוספת לעשות פונקציה דומה, שמחזירה תשובה של IActionResult וגם משתמשת בפונקציות קיצור.

בפונקציה הבאה – אני עושה בדיוק את אותה פעולה – עדכון רשומה, רק שאני נצמד לשיטה שמוצגת באתר של מיקרוסופט :

 [HttpPut("update2/{id}")]
 public IActionResult Update2([FromRoute] int id, [FromBody] Post post)
 {
 if (post == null || post.Id != id)
 {
 return BadRequest();
 }
 Post po = _appContext.Posts.FirstOrDefault(x => x.Id == id);
 if (po == null)
 {
 return NotFound();
 }
 po.Title = post.Title;
 po.Content = post.Content;
 _appContext.Posts.Update(po);
 _appContext.SaveChanges();
 return new NoContentResult();
 }

בשלב זה, כבר אפשר לשאול – מה עדיף ? שימוש ב- HttpResponseMessage או החזרה של IActionResult.

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

 

דוגמא 5 – פעולת מחיקה באמצעות הפועל Http Delete

כמו בדוגמא הקודמת, נדגים ראשית באמצעות החזרת HttpResponseMessage.

היות ואני לא מגדיר פה שם מפורש לניתוב ( route) אזי בעצם הניתוב של הקלאס עצמו משמש פה, בתוספת הפרמטר id  שהגדרתי.

[HttpDelete("{id}")]
 public HttpResponseMessage Delete([FromRoute] int id)
 {
 try
 {


 Post po = _appContext.Posts.FirstOrDefault(x => x.Id == id);

 if (po == null)
 {
 return new HttpResponseMessage(System.Net.HttpStatusCode.NotFound);
 }
 else
 {
 _appContext.Posts.Remove(po);

 if (_appContext.SaveChanges() > 0)
 {
 return new HttpResponseMessage(System.Net.HttpStatusCode.OK);
 }
 else
 {
 return new HttpResponseMessage(System.Net.HttpStatusCode.BadRequest);
 }
 }
 } catch(Exception e)
 {
 return new HttpResponseMessage(System.Net.HttpStatusCode.BadRequest);
 }
 }

ודוגמא נוספת, לעשות את אותה פעולה, עם פונקציות קיצור ועם החזרת IActionResult .

[HttpDelete("delete2/{id}")]
 public IActionResult Delete2(int id)
 {
 Post po = _appContext.Posts.FirstOrDefault(x => x.Id == id);
 if (po == null)
 {
 return NotFound();
 }
 _appContext.Posts.Remove(po);
 _appContext.SaveChanges();
 return new NoContentResult();
 }

מקורות נוספים :

https://docs.microsoft.com/en-us/aspnet/core/tutorials/first-web-api

 

 

טיפ קטן להאיץ את הדיבאג באפליקציות ASP.NET

באפליקציות ASP.NET , כל מתכנת מכיר את העובדה שכאשר באים להריץ, אז מתבצע build , ולאחריו, פתיחת instance נפרד של דפדפן, שמיועד עבור דיבוג.

ה-Instance הזה תמיד נפתח לאט מאוד,

הטריק כדי להתעלם ממנו, ועדין להיות מסוגל לדבג בצד שרת, הוא לבטל את האפשרות לדיבוג של JS .

ב-Visual Studio > נלחץ על Tools > נבחר ב-Options > נבחר ב- Debuging > ושם נסיר את הסימון מ- Enable JavaScript Debugging for ASP.NET  (Chrome And IE)

וזהו… זה מאיץ מאוד את פתיחת הדפדפן.

 

אפשרות שניה, אם רוצים לוותר לגמרי על דיבוג היא להריץ ב- Ctrl+f5  ( במקום ב-f5 ) , ואז אפשרויות הדיבוג נעלמות, אבל האפליקציה עולה מהר.

 

קונטרולרים Asp.Net core Web api

תזכורת – מהם קונטרולרים ?

קונטרולרים הם הקלאסים שמבצעים את הפעולות בפועל.

בתבנית הבסיסית שנותן לנו visual studio מופיעים 2 מאפיינים מעל שם המחלקה

 [Produces("application/json")]
 [Route("api/Post")]
 public class PostController : Controller

המאפיין Produces מגדיר מה יוחזר מהקונטרולר.

המאפיין Route מגדיר את ניתוב ברירת המחדל לקונטרולר הזה, כאשר הפונקציות ( actions ) עצמן, שם הפוקנציה יהיה המשך ה-URL.

הזרקת התלות של החיבור לדאטאבייס

ב-asp.net core , החיבור לדאטאבייס מוגדר כ-service שצריך להזריק לכל מחלקה שזקוקה לו.

לצורך ההזרקה שלו, פשוט נוסיף אותו כפרמטר של הקונסטרקטור.

 private readonly MyDbContext _appContext;

 public PostController(MyDbContext db)
 {
 _appContext = db;
 }

יצירת הפונקציות = נקודות הגישה של ה-Api

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

[HttpGet]
public IActionResult Get()
{
 return Ok(this.db.Post.ToList());
}

[HttpGet("{id}")]
public IActionResult Get(int id)
{
 return Ok(this.db.Post.FirstOrDefault(x=>x.Id == id));
}

יש לנו פה 2 פונקציות, שברור מהמאפיין HttpGet, שהם עובדות דרך GET.

הפונקציה הראשונה לא מצפה לקבל כלום, ולכן כאשר נגלוש אל localhost/api/post

נקבל את התוצאה של הפונקציה הראשונה כברירת מחדל – כלומר את כל הרשומות.

הערה : במקומות שבהם כתבתי localhost -זה יכול להשתנות כמובן לפי הפורט שקובע עבורכם הויזואל סטודיו.

הפונקציה השניה, היא OverLoad של הראשונה, עם חתימה מעט שונה – יש בה פרמטר של id שמאפשר לסנן את הרשומה המוחזרת.

כלומר אם נגלוש אל localhost/api/post?id=5 אז נקבל את רשומה 5.

כעת דוגמא לפונקציה שמקבלת POST   ( שימו לב שגם המודל של Entity אצלי בדוגמא נקרא Post, זה יכול קצת לבלבל, אבל כשמבינים את העיקרון – זה מובן).

[HttpPost]
public IActionResult Post([FromBody] Post post)
{
 this.db.Post.add(Post);
 this.db.SaveChanges();
 return Created("Get",post);
 
}

ברגע שנפנה בפעולת POST אל localhost/api/post אז נשלח בתוך ה-body של ה-Request אובייקט json שיכיל את המאפיינים של המודל post שלנו (לא להתבלבל עם הפועל POST של http).

ואנחנו נכניס אותו לדאטאבייס , ונחזיר תשובה שהוא נוצר בהצלחה.

מעט שליטה בשמות של נקודות הגישה (EndPoints ) של ה-Api – כלומר Routing

יש הרבה מאוד שליטה ב-Routing של Asp.net core web api , אני לא אעבור על הכל, רק אדגים אפשרות אחת לשלוט ב-url.

בדוגמאות הקודמות שלנו , כלל לא משנה איך קראנו לפונקציה, אלא כיוון שלא הוגדר שום route מיוחד, אז הפריימוורק web api הניח שיש פונקציה אחת שמטפלת בפעולת GET ואחת שמטפלת ב-POST, ולמעשה הסיבה היחידה שהפריימוורק לא החזיר שגיאה על הפונקציה השניה שטיפלה ב=GET, היא כיוון שהיא קיבלה פרמטר, אז הפריימוורק "הבין" מתי לפנות לכל אחת מהפונקציות.

אבל במקרה בו נרצה להחליט בעצמנו איך יקראו ה-EndPoints אז אחת השיטות היא לשים את השם הרצוי בתוך פועל ה-Http

למשל הדוגמא הבאה מהאתר של מיקרוסופט , ממחישה זאת :

[HttpGet("/products")]
public IActionResult ListProducts()
{
 // ...
}

[HttpPost("/products")]
public IActionResult CreateProduct(...)
{
 // ...
}

הערה חשובה :  בדוגמא שהבאתי כאן , הוספתי סימן "קו נטוי" / לפני הניתוב, מה שגורם לכתובת למעשה להיות ממש כמו שהיא כתובה בסוגרים , כלומר זה http://localhost/products , וזה לא  משתרשר לפי ה-attribute של הקלאס (אם היה כזה) .

אבל אם נוריד את סימן הקו נטוי בהתחלה, אז זה ישתרשר בהמשך לניתוב (route) שמוגדר לקונטרולר.

אז נניח והקונטרולר שלנו מתחיל כמו הדוגמא הראשונה בפוסט הזה,

אז התוצאה תהיה כך http://api/post/products .

שליפה של נתונים מתוך הכתובת \ body וכדומה.

כדי לשלוף נתונים מתוך הכתובת, כלומר מתוך ה- query string , אז ברוב המקרים מספיק פשוט להוסיף פרמטר של הפונקציה שמקביל בשמו לפרמטר שמגיע בכתובת.

יחד עם זאת, אם רוצים לקחת מתוך כתובת "יפה" ללא הסימן שאלה, וכדומה, אז אפשר להוסיף ברשימת הפרמטרים כל מיני מאפיינים שמאפשרים לשלוט במקור של הפרמטר, כלומר מאפשרים לומר מהיכן יגיע הפרמטר:

להלן 2 דוגמאות :

 public IActionResult Update2([FromRoute] int id, [FromBody] Post post)

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

בפוסט אחר, הבאתי דוגמאות רבות לפונקציות שמבצעות CRUD בקונטרולרים, וכיצד להחזיר תשובות Http שונות בכל מיני צורות.

יצירת Controllers באופן אוטומטי בעזרת Visual Studio

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

  • לוחצים מקש ימני על מקום מסוים בפרויקט
  • בוחרים ב- Add
  • Controller
  • ובמסך שיפתח נבחר בקונטרולר עבור ASP.NET Web Api  עם כל התכונות, ועם Entity וכו'
  • ואז בוחרים מודל רלוונטי, ו-Context, ובזה סיימנו.
  • כדאי כמובן לעבור על הקוד שנוצר לפני שמשתמשים בו.

מקורות להרחבה :

באופן כללי

https://docs.microsoft.com/en-us/aspnet/core/tutorials/first-web-api

https://docs.microsoft.com/en-us/aspnet/core/mvc/controllers/routing

לגבי Attributes ששולטים במקור של הפרמטרים :

https://docs.microsoft.com/en-us/aspnet/web-api/overview/formats-and-model-binding/parameter-binding-in-aspnet-web-api

Asp.Net Core Model Binding: Controlling The Binding Source

יצירת Migartions ב-ASP.NET

כאשר עובדים עם דאטאבייס רלציוני, אחד הנושאים שצריך לחשוב איך לעשות אותם נכון הוא עדכון המבנה של הדאטאבייס, שדות נוספים, מתחלפים, שמות משתנים, מאפיינים משתנים וכו' וכו', יש "חיים" לדאטאבייס.

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

איך עושים Migations ב-ASP.NET ?

הנחת יסוד :

 

  • מוגדר Connection תקין
  • קיים ב-Startup.cs הגדרה של הזרקת תלויות DI לקונקשיין.
  • יש תיקית Models , עם קלאסים מוכנים שמייצגים טבלאות.

דרך א לייצר Migrations

  • דרך Tools, או דרך מקש ימני על הפרויקט, נפתח את Nuget Manager Console
  • נקליד
Add-Migration YOUR_MIGRATION_NAME

לאחר כמה שניות של הרצה, נוצרת תיקיה בשם Migrations, ובתוכה נוצר קלאס בשם שביקשנו.

הערה :  אם הקלאס שיצרתם ל-DbContext הוא בשם שיכול להיות דו-משמעותי, למשל AppContext, אז תיכנסו למיגרשיון שנוצר, ותתנו הפניה מדוייקת שכוללת את שם ה Namespace, אחרת כמובן זה לא יעבוד.

 

דרך ב ליצירת Migrations

דרך נוספת היא ליצור את ה Migrations דרך שורת הפקודה הרגילה.

לצורך כך צריך לוודא שמותקנת חבילת    nuget מסויימת.

איך להריץ את ה-MIgrations כך שיעדכנו את המבנה ב-Database

הגיע רגע האמת.

הרצה מתוך Visual Studion

  • בתוך Package Manager Console נקליד
Update-Database

איך זה עובד

  • נוצרת בדאטאבייס טבלת ניהול בשם migrations, שמתעדת איזה מהעדכונים כבר הורצו ואיזה עדין לא.
  • בצורה הזו, הקוד "יודע" איך לעדכן את ה-DB שלנו.

EntityFrameworkCore – ירושה ממחלקת בסיס

העיקרון של ירושה בתיכנות מונחה עצמים, יכול לעזור במשהו נחמד בשימוש ב-ORM. לכל טבלה הרי יש בדרך כלל מפתח ראשי, ועמודות "ניהול" כמו created_at , updated_at ולעיתים עוד. מה יותר נחמד מאשר ליצור מחלקת בסיס שתכיל את המאפיינים האלו, וכך נחסוך כמה שורות קוד.

להלן דוגמא למימוש :

 public class EntityBase
 {
 public int Id { get; set; }
 public DateTime CreatedAt { get;set }

 }

 public class Category : EntityBase
 {
 public string CategoryName { get; set; }

 public virtual ICollection<Post> Posts { get; set; }
 }

 public class Post:EntityBase
 {

 public string Title { get; set; }

 public string Content { get; set; }

 public virtual Category Category { get; set; }
 }

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

למשל

 public class EntityBase
 {
 public EntityBase()
 {
 CreatedAt = DateTime.Now;

 }

 public int Id { get; set; }
 public DateTime CreatedAt { get;set }

 }

 

EntityFrameworkCore – ליצור תלויות בין ישויות

דרך אחת ליצור תלויות בין ישויות ב- Entity Framework Core היא להכריז על מאפיינים וירטואלים.

למשל – נניח שיש לנו יחס כזה – אחד לרבים קלאסי :

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

אז נוסיף לקלאס של הפוסט – קישור ל "אבא" הקטגוריה :

 public class Post
 {
 public int Id { get; set; }

 public string Title { get; set; }

 public string Content { get; set; }

 public virtual Category Category { get; set; }
 }

ונוסיף לקלאס של הקטגוריה – קישור ל "בנים" הפוסטים :

public class Category
 {
 public int Id { get; set; }
 public string Category { get; set; }

 public virtual ICollection<Post> Posts { get; set; }
 }

מה הערך של משתנים וירטואלים ? האם אפשר להפוך אותם ללא וירטואלים.

  • כן, אפשר. היתרון הקטן שזה נותן כאשר זה נשאר וירטואלי הוא ב -lazy loading . כלומר טעינת התלויות היא "עצלנית" = במובן שהיא מתרחשת מאליה, ברגע ששלפנו את האבא, ישלפו אוטומטית גם הבנים התלויים בו.. השיטה הזו מסייעת ליעילות
    מכך אפשר להבין שכאשר זה לא וירטואלי – אזי זה לא כך.

 

הסבר נחמד אפשר למצוא כאן.

 

תיעוד רשמי : https://docs.microsoft.com/en-us/ef/core/modeling/relationships 

 

Entity Framework Core – יצירת מודלים וחיבור ל Database

רקע – Entity Framework

Entity Framwork היא ORM של מיקרוסופט, כלומר, כלי (=ספריה) שמשמש בתיכנות לגישה קלה לנתונים, לעבודה קלה יותר עם דאטאבייסים (אך לא רק).

הרעיון מבוסס על כך שיש לנו "מודל" לכל ישות, וכל מודל מקושר לטבלה מסויים ב-DB (רלציוני, ול-collection ב-DB לא רלציוני).

יצירת מודלים ב Entity Framework Core

הרעיון – שמודל מייצג טבלה בדאטאבייס, או ישות אחרת.
לרוב – מודל מייצג טבלה כמו שהיא.
אך קיימים מקרים, בהם מודל מייצג גם יותר שדות מאשר בטבלה ( לדוגמא, כולל שדות מחושבים), או בכלל מייצג ישות שלא קיימת כמות שהיא בדאטאבייס.

במודל – כל שדה, מקביל לשדה בטבלה ( אפשר לבטל את הקישור הזה, אבל לצורך הלימוד, נתמקד באפשרות הרגילה הזו).

שם הטבלה – יכול להיות מקביל *בדיוק* לשם הקלאס, או שאפשר לקבוע אותו באמצעות מאפיין ( Attribute )
בצורה הבאה

[Table("Posts")]
 public class Post
 {

 

לצורך ההדגמה, לפני שניגש להתעסק עם דאטאבייס אמיתי, נתעסק תחילה עם דאטאבייס בזיכרון בלבד, מה שנקרא InMemory
לשם כך נתקין את חבילות הנוגט הבאות :
Microsoft.EntityFramewordCore.InMemory

יש 3 דרכים (לפחות) להתקין חבילות של nuget :

  1.  מקש ימני על הפרוייקט – לבחור באפשרות Manage nuget packages ולחפש ולהתקין את הספריה.
  2. דרך תפריט Tools (או מקש ימני על הפרויקט ) לפתוח את nuget package manager -> Package manager console , ואז להקליד
    Install-package YourPackageExactName
    במקרה כזה – כדי להעתיק את הפקודה המדוייקת מהאתר של nuget.
  3. מקש ימני על הפרוייקט – Edit YOUR_PROJECT_NAME.csproj
    ואז להוסיף ענף בקובץ ה-XML שמכיל את הספריה הרלוונטית .
    ברגע ששומרים את הקובץ, ה-Visual studio מזהה את השינוי, ומתקין את הספריה.

יצירת Context

המונח Context הוא במילים אחרות "חיבור" , כלומר אנחנו הולכים ליצור חיבור לדאטאבייס. בשפות תיכנות אחרות זה נקרא Connection וכדומה. בסופו של דבר מדובר בסה"כ במחלקה עם הגדרות, אותה מחלקה תכיל רשימת מחלקות אחרות – שהם הישויות הרלוונטיות ( ה- Entities ).
ובסופו של דבר, המחלקה הזאת תוזרק (DI ) אל כל מחלקה שצריכה חיבור לדאטאבייס.
בדוגמא הנוכחית אנחנו נגדיר DbContext (=חיבור) אל דאטאבייס בזיכרון.

ניצור מחלקה שנקרא לה ApiContext, ונגדיר שהיא יורשת מ- DbContext .
במחלקה הזאת נגדיר פונקצית קונסטרטור, בצורה המוצגת למטה, ובהמשך, נרשום את שמות הטבלאות, בתור מאפיינים מסוג dbSet של המחלקה.

public class ApiContext : DbContext
 {
 public ApiContext(DbContextOptions<ApiContext> options) : base(options)
 {

}

public DbSet<Post> Posts { get; set; }


 }

עכשיו, נגדיר בקובץ Startap.cs את ההגדרות הנחוצות, כדי שנוכל להזריק את ה- DbContext שיצרנו אל כל מחלקה שתרצה להשתמש בו.
כך זה נראה

 // This method gets called by the runtime. Use this method to add services to the container.
 public void ConfigureServices(IServiceCollection services)
 {
 services.AddDbContext<ApiContext>(options => options.UseInMemoryDatabase("Hi"));
 services.AddMvc();
 }

 

חיבור לדאטאבייס אמיתי

כדי להתחבר לדאטאבייס אמיתי, צריך לעשות כמה דברים :

  • להתקין חבילת nuget, שתהווה את הדרייבר אל הדאטאבייס הספציפי.
  • להגדיר Connection String בקובץ הגדרות, ולדאוג לשלוף את ההגדרה במקום הנכון.

דוגמא 1 : שימוש ב-SqlServer

  • בתור דרייבר — נתקין את חבילת ה nuget שנקראת Microsoft.EntityFrameworkCore.SqlServer
  • לצורך ההגדרה – נפתח את קובץ appsetting.json, ונגדיר בו קטע של ConnectionStrings

השם שהענקתי לאלמנט ה-JSON, כלומר "MyConnectionString", הוא השם שישמש אותי אחר כך ליצור service שמוזרק בעת הצורך.

כדי להקל על כתיבת המחרוזת, השתמשתי ב-Server Explorer שמובנה בתוך Visual Studio.

 "ConnectionStrings": {
 "MyConnectionString": "Data Source=LAPTOP-JD3DQ8JM\\SQLEXPRESS;Initial Catalog=EZCourse;Integrated Security=True"
 }
  • לצורך יצירת ה-service , הוספתי בפונקציה configureServices שנמצאת בקובץ startap.cs את הקטע הבא :
public void ConfigureServices(IServiceCollection services)
 {
 var connectionString = Configuration.GetConnectionString("MyConnectionString");
 services.AddDbContext<Models.AppContext>(options => options.UseSqlServer(connectionString));
 services.AddMvc();
 }