ASP.NET Core MVC Application for CURD Operation.

 

View Part

1. Create.cshtml

@model BookStorage.Models.Book
@{
    ViewData["Title"] = "Add Book";
}
<h2>Add Book</h2>

<form asp-action="Create" method="post">
    <div class="form-group">
        <label asp-for="Title"></label>
        <input asp-for="Title" class="form-control" />
        <span asp-validation-for="Title" class="text-danger"></span>
    </div>
    <div class="form-group">
        <label asp-for="Author"></label>
        <input asp-for="Author" class="form-control" />
        <span asp-validation-for="Author" class="text-danger"></span>
    </div>
    <div class="form-group">
        <label asp-for="YearPublished"></label>
        <input asp-for="YearPublished" class="form-control" />
        <span asp-validation-for="YearPublished" class="text-danger"></span>
    </div>
    <div class="form-group">
        <label asp-for="Price"></label>
        <input asp-for="Price" class="form-control" />
        <span asp-validation-for="Price" class="text-danger"></span>
    </div>
    <button type="submit" class="btn btn-success">Save</button>
</form>

2. Edit.cshtml

@model BookStorage.Models.Book
@{
    ViewData["Title"] = "Edit Book";
}
<h2>Edit Book</h2>
<form asp-action="Edit" method="post">
    <input type="hidden" asp-for="BookId" />

    <div class="form-group">
        <label asp-for="Title"></label>
        <input asp-for="Title" class="form-control" />
        <span asp-validation-for="Title" class="text-danger"></span>
    </div>

    <div class="form-group">
        <label asp-for="Author"></label>
        <input asp-for="Author" class="form-control" />
        <span asp-validation-for="Author" class="text-danger"></span>
    </div>

    <div class="form-group">
        <label asp-for="YearPublished"></label>
        <input asp-for="YearPublished" class="form-control" />
        <span asp-validation-for="YearPublished" class="text-danger"></span>
    </div>

    <div class="form-group">
        <label asp-for="Price"></label>
        <input asp-for="Price" class="form-control" />
        <span asp-validation-for="Price" class="text-danger"></span>
    </div>

    <button type="submit" class="btn btn-primary">Update</button>
    <a asp-action="Index" class="btn btn-secondary">Cancel</a>
</form>
@section Scripts {
    @{
        await Html.RenderPartialAsync("_ValidationScriptsPartial");
    }
}

3. Index.cshtml

@model IEnumerable<BookStorage.Models.Book>
@{
    ViewData["Title"] = "Book List";
}
@if(TempData["SuccessMessage"] != null)
{
    <div class="alert alert-success alert-dismissible fade show" role="alert">
        @TempData["SuccessMessage"]
        <button type="button" class="btn-close" data-bs-dismiss="alert" aria-label="Close"></button>
    </div>
}
<h1>@ViewData["Title"]</h1>
<p>
    <a asp-action="Create" class="btn btn-primary">Add New Book</a>
</p>
<table class="table table-bordered">
    <thead>
        <tr>
            <th>Title</th>
            <th>Author</th>
            <th>Published Year</th>
            <th>Price</th>
            <th></th>
        </tr>
    </thead>
     <tbody>
          @foreach (Book book in Model)
          {
              <tr>
                  <td>@book.Title</td>
                  <td>@book.Author</td>
                  <td>@book.YearPublished</td>
                  <td>@book.Price</td>
                  <td>
                      <a asp-action="Edit" asp-route-id="@book.BookId" class="btn btn-warning">Edit</a> |
                      <a asp-action="Details" asp-route-id="@book.BookId" class="btn btn-info">Details</a> |
                      <a asp-action="Delete" asp-route-id="@book.BookId" class="btn btn-danger">Delete</a>
                  </td>
              </tr>
          }
     </tbody>
</table>

Controller

1. BookController.cs

using BookStorage.Data;
using BookStorage.Models;
using Microsoft.AspNetCore.Mvc;

namespace BookStorage.Controllers
{
    public class BookController : Controller
    {
        private readonly AppDbContext _context;

        public BookController(AppDbContext context)
        {
            _context = context;
        }
        [HttpGet]
        [Route("books")]
        public IActionResult Index()
        {
            return View(_context.Books.ToList());
        }

        [HttpGet]
        public IActionResult Create()
        {
            return View();
        }

        [HttpPost]
        [ValidateAntiForgeryToken]
        public IActionResult Create(Book book)
        {
            if (ModelState.IsValid)
            {
                book.BookId = Guid.NewGuid();
                _context.Books.Add(book);
                _context.SaveChanges();
                TempData["SuccessMessage"] = "Book created successfully!";
                return RedirectToAction(nameof(Index));
            }
            return View(book);
        }
        [HttpGet]
        public IActionResult Edit(Guid id)
        {
            var book = _context.Books.Find(id);
            if (book == null) return NotFound();
            return View(book);
        }
        [HttpPost]
        [ValidateAntiForgeryToken]
        public IActionResult Edit(Guid id, Book book)
        {
            if (id != book.BookId) return NotFound();

            if (ModelState.IsValid)
            {
                _context.Update(book);
                _context.SaveChanges();
                return RedirectToAction(nameof(Index));
            }
            return View(book);
        }
        public IActionResult Delete(Guid id)
        {
            var book = _context.Books.Find(id);
            if (book == null) return NotFound();
            return View(book);
        }
        [HttpPost, ActionName("Delete")]
        [ValidateAntiForgeryToken]
        public IActionResult DeleteConfirmed(Guid id)
        {
            var book = _context.Books.Find(id);
            if (book != null)
            {
                _context.Books.Remove(book);
                _context.SaveChanges();
            }
            return RedirectToAction(nameof(Index));
        }
        public IActionResult Details(Guid id)
        {
            var book = _context.Books.Find(id);
            if (book == null) return NotFound();
            return View(book);
        }
    }
}

Program.cs

using BookStorage.Data;
using Microsoft.EntityFrameworkCore;

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
builder.Services.AddControllersWithViews();

builder.Services.AddDbContext<AppDbContext>(options =>
    options.UseSqlServer(builder.Configuration.GetConnectionString("DefaultConnection") ?? throw new InvalidOperationException("Connection string 'BookStorageContext' not found.")));
var app = builder.Build();

// Configure the HTTP request pipeline.
if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Home/Error");
    // The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapControllerRoute(
    name: "default",
    pattern: "{controller=Home}/{action=Index}/{id?}");

app.Run();

AppDbContext.cs

using BookStorage.Models;
using Microsoft.EntityFrameworkCore;

namespace BookStorage.Data
{
    public class AppDbContext : DbContext
    {
        public AppDbContext(DbContextOptions<AppDbContext> options) : base(options) { }

        public DbSet<Book> Books { get; set; }
    }
}

Angular Code- https://chatgpt.com/s/t_68c1e70776f88191a1eadd9fe7191f1a

CTEs (Common Table Expression)

Common Table Expressions (CTEs) are one of the most powerful and readable features in SQL. They help break down complex queries, improve code readability, and allow the use of recursion. In technical interviews, especially with top companies like Deloitte, TCS, Infosys, and Accenture, CTE-related questions are frequently asked to assess your problem-solving skills and query structuring ability.

What is a CTE?

A CTE (Common Table Expression) is a temporary result set that you can reference within a SELECT, INSERT, UPDATE, or DELETE statement. It is defined using the WITH keyword.

Syntax of a CTE

WITH CTE_Name AS (
    -- Your SQL query here
    SELECT column1, column2
    FROM TableName
    WHERE condition
)
SELECT * FROM CTE_Name;

Why Use CTEs?

• To simplify complex joins and subqueries
• Improve readability and maintainability
• Enable recursive operations (e.g., hierarchical data)
• Can be self-referenced in recursive CTEs

Example 1: Basic CTE to Simplify a Query

Problem: Get employees whose salary is above average.

WITH AvgSalaryCTE AS (
  SELECT AVG(Salary) AS AvgSal FROM Employees
)
SELECT e.Name, e.Salary
FROM Employees e, AvgSalaryCTE a
WHERE e.Salary > a.AvgSal;

✅ Instead of writing the AVG as a subquery, we make the query more readable.

Example 2: Recursive CTE to Handle Hierarchies

Problem: Get a hierarchical list of employees reporting to a manager

WITH EmployeeHierarchy AS (
  SELECT EmployeeID, Name, ManagerID, 0 AS Level
  FROM Employees
  WHERE ManagerID IS NULL

  UNION ALL

  SELECT e.EmployeeID, e.Name, e.ManagerID, eh.Level + 1
  FROM Employees e
  JOIN EmployeeHierarchy eh ON e.ManagerID = eh.EmployeeID
)
SELECT * FROM EmployeeHierarchy;

✅ This is especially useful for displaying org charts or processing file system structures.

Example 3: Find the Second-Highest Salary.

Using DISTINCT and ORDER BY with OFFSET (SQL Server / PostgreSQL):

SELECT DISTINCT Salary
FROM Employees
ORDER BY Salary DESC
OFFSET 1 ROW FETCH NEXT 1 ROW ONLY;

Using ROW_NUMBER() (works in most RDBMS):

WITH RankedSalaryCTE AS (
  SELECT Name, Salary
    ROW_NUMBER() OVER (ORDER BY Salary DESC) AS Rowum
FROM Employees
)
SELECT Name, Salary
FROM RankedSalaryCTE
WHERE RowNum = 2;

Example 4: Write a Query to Get All EVEN Position Records.

WITH NumberedRows AS (
  SELECT *, ROW_NUMBER() OVER (ORDER BY ID) AS RowNum
  FROM Employees
)
SELECT *
FROM NumberedRows
WHERE RowNum % 2 = 0;

The ROW_NUMBER() that we have used in the above query is known as a WINDOW Function. Let's understand each of them with an example:

Window Function.

A Window Function performs a calculation across a set of rows that are related to the current row, without collapsing them into a single output row (unlike aggregate functions).

It operates over a “window” of rows defined by the OVER() clause, allowing you to perform operations like ranking, running totals, comparisons with previous/next rows, and more — all while keeping the original row structure.

 

Example: Let’s say you want to assign a row number to each employee based on their salary within each department:

SELECT Name, Department, Salary,
       ROW_NUMBER() OVER (PARTITION BY Department ORDER BY Salary DESC) AS RowNum
FROM Employees;

• PARTITION BY Department: Groups data by department.
• ORDER BY Salary DESC: Orders rows within each partition.
• ROW_NUMBER(): Assigns a unique number starting from 1 in each group.

Common Window Functions:

• ROW_NUMBER() – Unique sequence number
• RANK() / DENSE_RANK() – Ranking with or without gaps
• LAG() / LEAD() – Compare with previous/next row
• SUM(), AVG(), COUNT() – Running totals over a window

SOLID Principles and Design Pattern.

What is the SOLID Principle?

SOLID is an acronym for five key principles of object-oriented design that help create clean, scalable, testable, and maintainable code. These principles are especially useful when building layered applications like ASP.NET Core Web APIs or MVC apps.

SOLID stands for:

• S - Single Responsibility Principle
• O - Open/Closed Principle
• L - Liskov Substitution Principle
• I - Interface Segregation Principle
• D - Dependency Inversion Principle

Let's understand each point with an example:

1. Single Responsibility Principle (SRP)

Definition: A class should have only one reason to change.

In ASP.NET Core, separate business logic, data access, and controller logic.

❌ Bad Example (Violates SRP).

public class ProductService
{
    public void Save(Product p) { /* save to DB */ }
    public void SendEmail(Product p) { /* email logic */ }
}

✅ Good Example.

public class ProductService
{
    private readonly IProductRepository _repo;
    public ProductService(IProductRepository repo) => _repo = repo;
    
    public void Save(Product product) => _repo.Add(product);
}

public class EmailService
{
    public void SendEmail(Product p) { /* only email logic */ }
}

2. Open/Closed Principle (OCP)

Definition: Classes should be open for extension but closed for modification.

In ASP.NET Core, use interfaces and inheritance to extend behavior without changing existing code.

Example: Logging Different Formats

public interface ILoggerService
{
    void Log(string message);
}

public class FileLogger : ILoggerService
{
    public void Log(string message) { /* log to file */ }
}

public class DbLogger : ILoggerService
{
    public void Log(string message) { /* log to DB */ }
}

The system can now be extended with a new logger without modifying the existing services.

3. Liskov Substitution Principle (LSP)

Definition: Subclasses should be replaceable for their base class without breaking the app.

In ASP.NET Core, ensure service implementations follow expected behavior.

❌ Violates LSP

If one subclass throws NotImplementedException:

public class BrokenNotificationService : NotificationService
{
    public override void Send(string message)
    {
        throw new NotImplementedException(); // ❌ Violates LSP
    }
}

Good Example:

We have a base class, NotificationService, and two derived classes: EmailNotificationService and SmsNotificationService.

Base Class:

public abstract class NotificationService
{
    public abstract void Send(string message);
}

Derived Class:

public class EmailNotificationService : NotificationService
{
    public override void Send(string message)
    {
        Console.WriteLine($"Email sent: {message}");
    }
}

public class SmsNotificationService : NotificationService
{
    public override void Send(string message)
    {
        Console.WriteLine($"SMS sent: {message}");
    }
}

Usage (LSP in Action)

public class NotificationController
{
    private readonly NotificationService _service;

    public NotificationController(NotificationService service)
    {
        _service = service;
    }

    public void NotifyUser()
    {
        _service.Send("Hello, User!");
    }
}

You can now substitute EmailNotificationService or SmsNotificationService when injecting into NotificationController without changing any controller code:

var controller1 = new NotificationController(new EmailNotificationService());
controller1.NotifyUser(); // Output: Email sent: Hello, User!

var controller2 = new NotificationController(new SmsNotificationService());
controller2.NotifyUser(); // Output: SMS sent: Hello, User!

• Inheritance + LSP = Child classes must work in place of their base class.
• Avoid incomplete or broken implementations in subclasses.
• In ASP.NET Core, always ensure services or controller dependencies fully implement expected behavior.

4. Interface Segregation Principle (ISP)

Definition: Don’t force classes to implement unnecessary methods.

In ASP.NET Core, use smaller, specific interfaces.

❌ Bad Interface

public interface IProductService
{
    void Add();
    void Update();
    void ExportToExcel(); // not every implementation needs this
}

✅ Good Design

public interface ICrudService
{
    void Add();
    void Update();
}

public interface IExportService
{
    void ExportToExcel();
}

5. Dependency Inversion Principle (DIP)

Definition: High-level modules should not depend on low-level modules. Instead, both should depend on abstractions.

In ASP.NET Core, this is implemented via dependency injection (DI).

Example:

public interface IEmailService
{
    void Send(string to, string message);
}

public class SmtpEmailService : IEmailService
{
    public void Send(string to, string message)
    {
        // logic to send email
    }
}

public class NotificationController : ControllerBase
{
    private readonly IEmailService _emailService;

    public NotificationController(IEmailService emailService)
    {
        _emailService = emailService;
    }

    public IActionResult Notify()
    {
        _emailService.Send("user@example.com", "Hello!");
        return Ok();
    }
}

Applying SOLID principles in ASP.NET Core helps you build robust, clean, and future-proof applications. These principles make your code:

• Easier to test
• Simpler to maintain
• More scalable and flexible

I hope you understood the SOLID Principle and use case now. Let's understand a few popular Design Patterns that we follow while writing ASP.NET Core Code.

Design Patterns

1. Singleton Pattern.

The Singleton Pattern ensures that a class has only one instance throughout the application’s lifetime and provides a global point of access to that instance.

When to Use Singleton in ASP.NET Core

• Logging services
• Configuration settings
• Caching
• Shared services (only if thread-safe and stateless)

Example: Think of Logger: You want one shared logger throughout your app rather than creating a new one every time.

Step 1: Create the Singleton Class

public class AppLogger
{
    // Static instance
    private static readonly AppLogger _instance = new AppLogger();

    // Private constructor
    private AppLogger() { }

    // Public static property to access the instance
    public static AppLogger Instance => _instance;

    // Sample method
    public void Log(string message)
    {
        Console.WriteLine($"[LOG] {DateTime.Now}: {message}");
    }
}

Usage in Code:

class Program
{
    static void Main(string[] args)
    {
        var logger1 = AppLogger.Instance;
        var logger2 = AppLogger.Instance;

        logger1.Log("Singleton is working!");
        logger2.Log("Same instance is used again.");

        Console.WriteLine(ReferenceEquals(logger1, logger2)); // Output: True
    }
}

2. Factory Pattern.

The Factory Pattern is a creational design pattern that provides an interface for creating objects in a superclass but allows subclasses to alter the type of objects that will be created.

In simpler terms: You let a Factory class decide which object to create based on input, instead of using new everywhere.

In short, "The Factory Pattern lets me abstract the creation of objects based on input or logic. Instead of using new everywhere, I call a Factory method, which decides what class to return. This keeps my code flexible and clean."

When to Use the Factory Pattern

• When object creation logic is complex or repetitive
• When you want to decouple object creation from your main logic
• When the class to instantiate is determined at runtime

Example: You want to send different types of notifications — Email, SMS, or Push.

Step 1: Create a Common Interface.

public interface INotification
{
    void Send(string message);
}

Step 2: Create Concrete Implementations.

public class EmailNotification : INotification
{
    public void Send(string message)
    {
        Console.WriteLine("Email sent: " + message);
    }
}

public class SmsNotification : INotification
{
    public void Send(string message)
    {
        Console.WriteLine("SMS sent: " + message);
    }
}

public class PushNotification : INotification
{
    public void Send(string message)
    {
        Console.WriteLine("Push sent: " + message);
    }
}

Step 3: Create the Factory Class.

public class NotificationFactory
{
    public static INotification Create(string type)
    {
        return type.ToLower() switch
        {
            "email" => new EmailNotification(),
            "sms" => new SmsNotification(),
            "push" => new PushNotification(),
            _ => throw new ArgumentException("Invalid notification type"),
        };
    }
}

Step 4: Use the Factory in Your App.

class Program
{
    static void Main()
    {
        Console.Write("Enter notification type (email/sms/push): ");
        string type = Console.ReadLine();

        INotification notification = NotificationFactory.Create(type);
        notification.Send("Hello from Factory Pattern!");
    }
}

3. Repository Pattern.

The Repository Pattern is used to abstract the data access layer so your application code (like services or controllers) doesn't directly interact with the database.

This pattern helps:

• Centralized database logic
• Make the code more testable
• Enforce Separation of Concerns (SoC)

Example:

Think of the repository as a middleman between your app and the database.

Instead of writing EF Core queries inside your controller, you use a repository.

Step 1: Define a Model.

public class Product
{
    public int Id { get; set; }
    public string Name { get; set; }
    public decimal Price { get; set; }
}

Step 2: Create the DbContext.

public class AppDbContext : DbContext
{
    public DbSet<Product> Products { get; set; }

    public AppDbContext(DbContextOptions<AppDbContext> options)
        : base(options)
    {
    }
}

Step 3: Create Repository Interface.

public interface IProductRepository
{
    IEnumerable<Product> GetAll();
    Product GetById(int id);
    void Add(Product product);
    void Update(Product product);
    void Delete(int id);
}

Step 4: Implement Repository.

public class ProductRepository : IProductRepository
{
    private readonly AppDbContext _context;
    public ProductRepository(AppDbContext context)
    {
        _context = context;
    }

    public IEnumerable<Product> GetAll() => _context.Products.ToList();

    public Product GetById(int id) => _context.Products.Find(id);

    public void Add(Product product)
    {
        _context.Products.Add(product);
        _context.SaveChanges();
    }

    public void Update(Product product)
    {
        _context.Products.Update(product);
        _context.SaveChanges();
    }

    public void Delete(int id)
    {
        var product = _context.Products.Find(id);
        if (product != null)
        {
            _context.Products.Remove(product);
            _context.SaveChanges();
        }
    }
}

Step 5: Register in DI (Program.cs).

builder.Services.AddScoped<IProductRepository, ProductRepository>();
builder.Services.AddDbContext<AppDbContext>(options =>
    options.UseSqlServer(builder.Configuration.GetConnectionString("DefaultConnection")));

Step 6: Use the Repository in the Controller.

[ApiController]
[Route("api/[controller]")]
public class ProductsController : ControllerBase
{
    private readonly IProductRepository _repo;

    public ProductsController(IProductRepository repo)
    {
        _repo = repo;
    }

    [HttpGet]
    public IActionResult Get() => Ok(_repo.GetAll());

    [HttpPost]
    public IActionResult Post(Product product)
    {
        _repo.Add(product);
        return CreatedAtAction(nameof(Get), new { id = product.Id }, product);
    }
}

Q: Why use the repository pattern?

Answer: "It abstracts the data access logic, helps me write unit tests easily, and makes the app follow SOLID principles, especially SRP and DIP."

Clean Architecture in ASP.NET Core.

Before understanding Clean Architecture, let's first understand Three-Tier Architecture, and then we will understand how Clean Architecture is better compared to Three-Tier.

Three-Tier Architecture.

Three-Tier Architecture is a software design pattern that separates an application into three logical and physical layers, each with a specific responsibility.

Flow of Data in Three-Tier:

User (UI Layer)

   ↓

Controller → Calls Service (BLL)

   ↓

Service → Calls Repository (DAL)

   ↓

Repository → Talks to Database

Clean Architecture.

Clean Architecture is a powerful software design pattern that helps you organize your application into loosely-coupled, highly maintainable layers. It was popularized by Robert C. Martin (Uncle Bob) and is especially useful in large enterprise-level applications like those built with ASP.NET Core.

Why Clean Architecture?

• Separates concerns clearly
• Promotes testability
• Enables independent development of core logic and infrastructure
• Improves scalability and flexibility
• Encourages dependency inversion (core depends on nothing)

Core Principles of Clean Architecture

UI

• Controllers, Views, View Models
• Filters, Middleware

Core

• Business Logic Services
• Business Logic Interfaces
• Data Transfer Objects (DTO)

Domain

• Repository Interfaces
• Entity Classes

Infrastructure

• DbContext, Repositories
• External API Calls

Clean Architecture vs Three-Tier Architecture

Feature	Three-Tier Architecture	Clean Architecture
Layer Focus	Focuses on UI → BLL → DB separation	Focuses on core business logic and dependency flow
Dependency Flow	Flows UI → BLL → DAL	Always flows inward, toward the domain layer
Coupling	Higher coupling to frameworks (e.g., EF in BLL)	Loosely coupled; core has no external dependencies
Testability	Harder if BLL directly depends on infrastructure	High testability; core logic is isolated
Flexibility	Rigid – changing DB or UI may impact logic	Flexible – DB/UI are pluggable
Domain-Centric	No – business logic mixed with infrastructure	Yes – everything revolves around business rules
Use in Microservices	Not ideal	Highly suitable

AppSettings and IConfiguration

What is appsettings.json?

appsettings.json is a configuration file used in ASP.NET Core to store key-value pairs like:

• Database connection strings
• API keys
• Feature toggles
• Logging levels
• Custom settings

Example:

{  "AppSettings": {
    "AppName": "MyApp",
    "Version": "1.0"
  },
  "ConnectionStrings": {
    "DefaultConnection": "Server=.;Database=MyDb;Trusted_Connection=True;"
  }
}

What is IConfiguration?

IConfiguration is an interface provided by ASP.NET Core to access configuration data (like from appsettings.json, environment variables, etc.).

You can inject it into any class:

Example:

public class HomeController : Controller
{
    private readonly IConfiguration _config;

    public HomeController(IConfiguration config)
    {
        _config = config;
    }

    public IActionResult Index()
    {
        var appName = _config["AppSettings:AppName"];
        return Content($"App Name: {appName}");
    }
}

How to Bind Settings to a Class

You can also bind sections from appsettings.json to a class:

Step 1: Create a Class.

public class AppSettings
{
    public string AppName { get; set; }
    public string Version { get; set; }
}

Step 2: Register it in Program.cs

builder.Services.Configure<AppSettings>(
    builder.Configuration.GetSection("AppSettings"));

Step 3: Inject using IOptions<T>

public class HomeController : Controller
{
    private readonly AppSettings _settings;

    public HomeController(IOptions<AppSettings> options)
    {
        _settings = options.Value;
    }

    public IActionResult Index()
    {
        return Content($"App: {_settings.AppName}, Version: {_settings.Version}");
    }
}

ss

Enable Swagger and CROS in ASP.NET Core.

Swagger.

Swagger (OpenAPI) is a powerful tool that:

• Generates interactive API documentation
• Helps you test APIs right from the browser
• Makes your API self-descriptive for frontend teams and third-party users

How to configure Swagger?

If not already installed, add the package:

dotnet add package Swashbuckle.AspNetCore

Add Swagger services before building the app:

Example:

var builder = WebApplication.CreateBuilder(args);

// Add services
builder.Services.AddControllers();
builder.Services.AddEndpointsApiExplorer(); // For minimal API support
builder.Services.AddSwaggerGen();           // 👈 Adds Swagger generator

var app = builder.Build();

// Use middleware
if (app.Environment.IsDevelopment())
{
    app.UseSwagger();                        // 👈 Enables Swagger JSON
    app.UseSwaggerUI();                      // 👈 Enables Swagger UI
}

app.UseAuthorization();
app.MapControllers();
app.Run();

You can enhance your Swagger UI by providing API details:

builder.Services.AddSwaggerGen(options =>
{
    options.SwaggerDoc("v1", new OpenApiInfo
    {
        Title = "My API",
        Version = "v1",
        Description = "This is a sample Web API using Swagger.",
        Contact = new OpenApiContact
        {
            Name = "Probin Sah",
            Email = "probin@example.com"
        }
    });
});

What is CORS?

CORS (Cross-Origin Resource Sharing) is a security feature implemented by browsers that restricts web apps from making requests to a different domain than the one that served the web page.

Why is it needed?

By default, browsers block cross-origin requests to protect users. For example:

• If your Angular app runs on http://localhost:4200
• And your API runs on http://localhost:5000

The browser blocks requests from the Angular app to the API unless CORS is explicitly enabled.

How To Enable CORS in ASP.NET Core?

Step 1: Add CORS Services in Program.cs

builder.Services.AddCors(options =>
{
    options.AddPolicy("AllowFrontendApp", policy =>
    {
        policy
            .WithOrigins("http://localhost:4200") // Frontend URL
            .AllowAnyMethod()
            .AllowAnyHeader();
    });
});

Step 2: Use CORS Middleware

Place it before UseAuthorization():

var app = builder.Build();

app.UseCors("AllowFrontendApp"); // 👈 Apply the policy

app.UseAuthorization();
app.MapControllers();

app.Run();

• CORS allows your frontend (from another origin) to call your backend API.
• Without it, browsers block cross-origin calls for security.
• Use .WithOrigins, .AllowAnyMethod, .AllowAnyHeader to control access.