BSc CSIT (TU) Science NET Centric Computing (BSc CSIT, CSC367) Question Paper 2075 Nepal

Dependency Injection (DI) and the IoC Container in ASP.NET Core

Dependency Injection

Dependency Injection is a design pattern that implements Inversion of Control (IoC) for resolving dependencies. Instead of a class creating its own dependencies (e.g. new EmailService()), the dependencies are injected from outside — usually through the constructor. This makes code loosely coupled, testable, and easy to maintain (you can swap implementations without changing the consumer).

IoC Container

ASP.NET Core has a built-in IoC (Inversion of Control) container — the IServiceProvider. It is responsible for:

• Registering services (mapping an abstraction/interface to a concrete implementation), and
• Resolving them — automatically creating objects and supplying their dependencies (and the dependencies of those dependencies) when needed.

Three lifetimes

Registering a Service

Services are registered in the DI container (in Program.cs for .NET 6+, or Startup.ConfigureServices earlier):

public interface IMessageService
{
    string Send(string to, string body);
}

public class EmailService : IMessageService
{
    public string Send(string to, string body) => $"Email sent to {to}: {body}";
}

// Program.cs
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddControllersWithViews();
builder.Services.AddScoped<IMessageService, EmailService>();   // register

Consuming a Service

The container injects the service through the constructor — the developer never calls new:

public class HomeController : Controller
{
    private readonly IMessageService _message;

    public HomeController(IMessageService message)   // injected by the IoC container
    {
        _message = message;
    }

    public IActionResult Index()
    {
        var result = _message.Send("ram@example.com", "Hello");
        return Content(result);
    }
}

When a request hits HomeController, the IoC container sees the constructor needs an IMessageService, finds the registered EmailService, creates it, and passes it in.

Benefits

• Loose coupling between components
• Easier unit testing (inject mock/fake implementations)
• Centralized, configurable object lifetime management

ASP.NET Core Request Processing Pipeline and Middleware

The Request Pipeline

In ASP.NET Core, every incoming HTTP request flows through a pipeline of middleware components. Each middleware:

1. Receives the HttpContext,
2. Optionally does work before the next component,
3. Calls await next() to pass the request down the chain,
4. Optionally does work after the next component returns (on the way back up).

This creates a request-and-response ("in and out") flow, often drawn as a series of nested handlers. A middleware can also short-circuit the pipeline (not call next) to immediately produce a response.

Request → [Logging] → [Authentication] → [Routing] → [Endpoint/MVC] Response ← [Logging] ← [Authentication] ← [Routing] ← [Endpoint/MVC]

Configuring the Pipeline

Middleware is added in Program.cs with Use... extension methods. Order matters — they execute in the order registered:

var app = builder.Build();

app.UseExceptionHandler("/Home/Error");
app.UseStaticFiles();      // serve files, may short-circuit
app.UseRouting();          // match endpoint
app.UseAuthentication();
app.UseAuthorization();
app.MapControllers();       // terminal middleware

app.Run();

Types of pipeline methods

• app.Use(...) — adds middleware that may call the next component.
• app.Run(...) — terminal middleware; does not call next.
• app.Map(...) — branches the pipeline based on the request path.

Writing a Custom Middleware Component

The recommended convention-based class needs a constructor that takes RequestDelegate next and an InvokeAsync(HttpContext) method:

public class RequestTimingMiddleware
{
    private readonly RequestDelegate _next;

    public RequestTimingMiddleware(RequestDelegate next) => _next = next;

    public async Task InvokeAsync(HttpContext context)
    {
        var sw = System.Diagnostics.Stopwatch.StartNew();

        await _next(context);          // call the next middleware

        sw.Stop();
        var ms = sw.ElapsedMilliseconds;
        context.Response.Headers["X-Response-Time-ms"] = ms.ToString();
    }
}

// Optional extension method for clean registration
public static class RequestTimingMiddlewareExtensions
{
    public static IApplicationBuilder UseRequestTiming(this IApplicationBuilder app)
        => app.UseMiddleware<RequestTimingMiddleware>();
}

Register it in the pipeline:

app.UseRequestTiming();

Now every request is timed, and the elapsed time is added as a response header before the response is returned to the client.

URL Routing in ASP.NET Core

Routing is the mechanism that matches an incoming request URL to an endpoint (a controller action or Razor page) and extracts route values from the URL. It is enabled by app.UseRouting() and app.UseEndpoints(...) (or app.MapControllerRoute(...)). ASP.NET Core supports two styles: conventional routing and attribute routing.

1. Conventional Routing

A central route template defines a pattern of segments. Tokens like {controller}, {action}, and {id?} are filled from the URL. It is defined once and applies to all matching controllers — well suited to traditional MVC apps.

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

Example mapping:

• URL /Products/Details/5 → ProductsController.Details(id = 5)
• URL / → HomeController.Index() (uses the defaults)

The =Home / =Index are default values; the ? makes id optional.

2. Attribute Routing

Routes are declared directly on controllers and actions using [Route], [HttpGet], [HttpPost], etc. This gives precise, per-action control over URLs and is the standard for Web APIs / RESTful services.

[Route("api/products")]
public class ProductsController : ControllerBase
{
    [HttpGet]                    // GET api/products
    public IActionResult GetAll() => Ok(/* ... */);

    [HttpGet("{id:int}")]        // GET api/products/5
    public IActionResult Get(int id) => Ok(/* ... */);

    [HttpPost]                    // POST api/products
    public IActionResult Create([FromBody] Product p) => Created(/* ... */);
}

Here {id:int} is a route constraint that only matches integers.

Comparison

Both can be used together; attribute routes take precedence when present.

TempData vs ViewData vs ViewBag

All three pass data from a controller to a view, but differ in scope and type:

Key points

• ViewData and ViewBag are two faces of the same data — ViewBag is just a dynamic, syntactically simpler wrapper around ViewData. Both are lost after the current request.
• TempData survives a redirect (one extra request), which makes it ideal for the Post-Redirect-Get pattern, e.g. showing "Record saved successfully" after a redirect. It can be retained with TempData.Keep().

ViewData["Title"] = "Home";        // cast when reading
ViewBag.Title = "Home";           // no cast
TempData["Msg"] = "Saved!";       // available after RedirectToAction

LINQ (Language Integrated Query)

LINQ is a feature of C#/.NET that provides a uniform, type-safe, query syntax to retrieve and manipulate data from different sources — in-memory collections (LINQ to Objects), databases (LINQ to Entities / EF Core), XML, etc. — directly within the language. It offers compile-time checking, IntelliSense, and many standard operators (Where, Select, OrderBy, GroupBy, Count, etc.).

LINQ can be written in two styles: query syntax and method (fluent) syntax.

LINQ query to filter a list of integers (keep even numbers)

List<int> numbers = new List<int> { 1, 2, 3, 4, 5, 6, 7, 8 };

// Query syntax
var evensQuery = from n in numbers
                 where n % 2 == 0
                 select n;

// Method syntax (equivalent)
var evensMethod = numbers.Where(n => n % 2 == 0);

foreach (int n in evensQuery)
    Console.WriteLine(n);   // Output: 2 4 6 8

Both queries filter the list to the even numbers {2, 4, 6, 8}. LINQ uses deferred execution — the query runs only when it is enumerated (e.g. in the foreach).

Lifecycle of a Request in ASP.NET Core MVC

When an HTTP request arrives, it passes through the following stages:

1. Middleware pipeline — The request first travels through registered middleware (exception handling, static files, HTTPS redirection, authentication, authorization, etc.).
2. Routing — UseRouting() matches the request URL against route templates and selects the target controller and action (the endpoint), extracting route values.
3. Authorization — UseAuthorization() checks any [Authorize] policies for the selected endpoint.
4. Controller instantiation — The IoC container creates the controller and injects its dependencies.
5. Model binding — Incoming data (route values, query string, form body, headers) is bound to the action method parameters/model.
6. Model validation — Data-annotation rules are evaluated and results placed in ModelState.
7. Action filters — Filters run before (OnActionExecuting) and after (OnActionExecuted) the action.
8. Action execution — The action method runs the business logic and returns an IActionResult (e.g. View(), Json(), Redirect()).
9. Result execution — For a ViewResult, the Razor view engine renders the view (with its model) into HTML.
10. Response — The generated response flows back up through the middleware and is sent to the client.

Thus the flow is: Request → Middleware → Routing → Controller → Model Binding/Validation → Action → Result/View → Response.

AddSingleton vs AddScoped vs AddTransient

These three methods register a service with the DI container but differ in the lifetime (how long an instance lives and when a new one is created):

builder.Services.AddSingleton<ICacheService, MemoryCache>();   // one for app
builder.Services.AddScoped<IUnitOfWork, UnitOfWork>();         // one per request
builder.Services.AddTransient<IEmailService, EmailService>();  // new each time

Guidance

• Singleton — for stateless, thread-safe, or shared/cached services (e.g. configuration, logging).
• Scoped — for per-request units of work such as an EF Core DbContext.
• Transient — for lightweight, stateless services.

Caution: never inject a scoped or transient service into a singleton (captive dependency), as it would keep that short-lived object alive for the whole application.

Garbage Collection in .NET

Garbage Collection (GC) is the automatic memory management system of the .NET CLR. It manages allocation and release of memory on the managed heap, freeing the developer from manually deallocating objects and preventing common bugs such as memory leaks and dangling pointers.

How it works

• Objects are allocated on the managed heap. When memory pressure rises, the GC runs.
• The GC determines which objects are reachable (still referenced by application roots — stack variables, static fields, CPU registers). Objects that are no longer reachable are considered garbage.
• Their memory is reclaimed, and the heap is compacted (surviving objects moved together) to reduce fragmentation.

Generations

The GC is generational for efficiency, based on the idea that most objects die young:

• Gen 0 — newly allocated, short-lived objects (collected most often, fastest).
• Gen 1 — objects that survived a Gen 0 collection (a buffer between short and long lived).
• Gen 2 — long-lived objects (collected least often). Large objects (≥ 85 KB) go on the Large Object Heap (LOH), collected with Gen 2.

Objects surviving a collection are promoted to the next generation.

Related points

• Finalizers (~ClassName) and IDisposable/Dispose() are used to release unmanaged resources (file handles, DB connections); the using statement ensures Dispose is called.

Benefit: automatic, safe memory reclamation, eliminating most manual memory-management errors.

Partial View

A partial view is a reusable, smaller Razor view (.cshtml) that renders a portion of HTML and is embedded inside another (parent) view. It does not run as a full page on its own; it produces a fragment of markup that is inserted into the host view.

When / why it is used

• Reusability — to avoid duplicating common UI markup (e.g. a product card, comment block, address form) across many views; define it once and reuse it.
• Modularity / maintainability — to break a large, complex view into smaller manageable pieces.
• Repeated rendering — to render the same markup for each item in a collection.
• AJAX / partial page updates — a controller can return PartialView(...) so only part of the page is refreshed without reloading the whole page.

Example

@* Views/Shared/_ProductCard.cshtml — the partial view *@
@model Product
<div class="card">
    <h3>@Model.Name</h3>
    <p>Rs. @Model.Price</p>
</div>

Rendering it from a parent view:

@foreach (var p in Model.Products)
{
    <partial name="_ProductCard" model="p" />
    @* or:  @await Html.PartialAsync("_ProductCard", p) *@
}

Returning a partial from a controller (e.g. for AJAX):

public IActionResult ProductCard(int id) => PartialView("_ProductCard", GetProduct(id));

By convention partial views are often named with a leading underscore (e.g. _ProductCard.cshtml).

Authentication vs Authorization in ASP.NET Core

Authentication

The process of confirming a user is who they claim to be, typically via username/password, a cookie, or a JWT token. On success the framework builds a ClaimsPrincipal (HttpContext.User) describing the identity. Enabled by app.UseAuthentication().

Authorization

Once identity is known, authorization decides whether that user may access a particular resource or action. ASP.NET Core supports role-based, claims-based, and policy-based authorization. Enabled by app.UseAuthorization().

[Authorize]                       // any authenticated user
public IActionResult Dashboard() => View();

[Authorize(Roles = "Admin")]     // only users in the Admin role
public IActionResult Settings() => View();

In short: authentication establishes identity; authorization enforces access control. Authentication must succeed before authorization can be evaluated — hence UseAuthentication() is registered before UseAuthorization().

Asynchronous Programming in C# (async / await)

Asynchronous programming lets a method start a long-running operation (file I/O, network calls, database queries) and return the calling thread to do other work instead of blocking it while waiting. This greatly improves responsiveness and scalability — e.g. a web server can serve other requests while one waits on a database. C# implements this with the Task-based Asynchronous Pattern (TAP) using the async and await keywords.

async

A modifier on a method that enables the use of await inside it. An async method typically returns:

• Task — for an async operation with no result,
• Task<T> — for one returning a value of type T,
• void — only for event handlers.

await

Applied to a Task. It asynchronously waits for the task to complete: the method is suspended at that point and control returns to the caller (the thread is freed). When the awaited task finishes, execution resumes after the await, and the result is unwrapped. The code stays sequential and readable, without blocking.

Example

public async Task<string> GetDataAsync()
{
    using var client = new HttpClient();
    // await frees the thread while the download is in progress
    string content = await client.GetStringAsync("https://api.example.com/data");
    return content;          // returned as Task<string>
}

// Calling it
string result = await GetDataAsync();

Key point: await does not block the thread (unlike Task.Result or .Wait(), which can cause deadlocks). It releases the thread until the operation completes, then continues.

Migrations in Entity Framework Core

In EF Core (a code-first ORM), the C# model/entity classes and DbContext define the database schema. Migrations are the mechanism that keeps the database schema in sync with the changes you make to those model classes over time — incrementally and without losing existing data.

Purpose

• Translate changes in entity classes (new entity, new property, renamed column, etc.) into incremental schema changes (CREATE TABLE, ALTER TABLE, etc.).
• Provide a version history of the schema, with the ability to upgrade or roll back.
• Apply the same schema consistently across development, test, and production databases.

How it works

Each migration is a generated C# class with two methods:

• Up() — applies the changes (e.g. create/alter tables).
• Down() — reverts them (for rolling back). EF also keeps a __EFMigrationsHistory table to track which migrations have been applied.

Typical commands

# 1. Create a migration after changing the model
dotnet ef migrations add InitialCreate

# 2. Apply pending migrations to the database
dotnet ef database update

# 3. Roll back to a previous migration
dotnet ef database update PreviousMigrationName

# 4. Remove the last (unapplied) migration
dotnet ef migrations remove

(The Package Manager Console equivalents are Add-Migration, Update-Database, etc.)

In short: migrations let you evolve the database schema in a controlled, repeatable, and reversible way directly from your C# code-first model.