Web API with .NET Core

 Entity Framework provides us a class called DbContext which is a gateway to our db, DbContext can have one or more DbSet which represent table in our db, we use LINQ to query these DbSet, Entity Framework translates these LINQ queries to SQL queries at runtime Two approaches: DB first Code first  

Migrations help us ensure that the database schema and the domain model in the appliation are in sync. In real world projects, data models change as features get implemented: new entities or properties are added and removed, and database schemas need to be changed accordingly to be kept in sync with the application. Migrations provides a way to incrementally update the database schema to keep it in sync with the application's data model while preserving existing data in the database. More on Migrations with EF (Entity Framework) here Dapper and Migrations: Dapper is a lightweight Object-Relational Mapping (ORM) library for .NET that provides a simple way to interact with databases. Unlike full-fledged ORMs like Entity Framework, Dapper does not have built-in support for database migrations. Instead, it focuses on efficiently executing SQL queries and mapping the results to .NET objects.

Default logging with ILogger occurs in console window but in production evironments, one may want to log in some file to refer to it later, here Serilog comes into play, to write logs to some file. We can inject ILogger into controller constructors as ILogger functionality comes with ASP.NET core public class AboutModel : PageModel { private readonly ILogger _logger; public AboutModel ( ILogger<AboutModel> logger ) { _logger = logger; } public void OnGet ( ) { _logger.LogInformation( "About page visited at {DT}" , DateTime.UtcNow.ToLongTimeString()); } }

  With ASP.NET Core there are various attributes that instruct the framework where to expect data as part of an HTTP request - whether the body, header, query-string, etc. With C#, attributes make decorating API endpoints expressive, readable, declarative and simple. These attributes are very powerful! They allow aliasing, route-templating and strong-typing through data binding; however, knowing which are best suited for each HTTP verb, is vital. e.g. Route Attribute ASP.NET Core provides a powerful Route attribute. This can be used to define a top-level route at the controller class – doing so leaves a common route that actions can expand upon. For example consider the following: [Route( "api/[Controller]" )] public class OrdersController : Controller {      [HttpGet( "{id}" )]      public Task<Order> Get([FromRoute] int id)          => _orderService.GetOrderAsync(id); The Route attribute ...

An action result is what a controller action returns in response to a browser request. The IActionResult return type is appropriate when multiple ActionResult return types are possible in an action. IActionResult and ActionResult work as a container for other action results, in that IActionResult is an interface and ActionResult is an abstract class that other action results inherit from. IActionResult type The  IActionResult  return type is appropriate when multiple  ActionResult  return types are possible in an action. The  ActionResult  types represent various HTTP status codes. Any non-abstract class deriving from  ActionResult  qualifies as a valid return type. Some common return types in this category are  BadRequestResult  (400),  NotFoundResult  (404), and  OkObjectResult  (200). Alternatively, convenience methods in the  ControllerBase  class can be used to return  ActionResult  types fr...