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

State Management in Stateless HTTP

HTTP is a stateless protocol — each request/response is independent and the server does not inherently remember anything about previous requests from the same client. To create the illusion of continuity (e.g. a logged-in user, a shopping cart), the application must explicitly store and re-associate state with each client across requests, typically by passing an identifier (such as a cookie or token) back and forth and storing the data either on the client or on the server keyed by that identifier.

State Management Techniques in ASP.NET Core

1. Cookies (Client-side)

Small key-value data stored in the browser and sent with every request to the same domain.

Response.Cookies.Append("theme", "dark");
string theme = Request.Cookies["theme"];

2. Session State (Server-side)

Data is kept on the server (in memory or a distributed cache) and identified by a session cookie holding the session ID.

// Program.cs
builder.Services.AddDistributedMemoryCache();
builder.Services.AddSession();
app.UseSession();

// In a controller
HttpContext.Session.SetString("User", "Ram");
string user = HttpContext.Session.GetString("User");

3. TempData

Used to pass data between two consecutive requests (e.g. across a redirect after a POST). Backed by session or cookies and cleared after it is read.

TempData["Message"] = "Record saved successfully";
// available in the next request only

4. Query Strings

State carried in the URL.

/products?category=books&page=2

string cat = Request.Query["category"];

5. Hidden Form Fields

Values round-tripped inside a form so they survive a POST.

<input type="hidden" asp-for="Id" />

6. Cache (Application-wide)

IMemoryCache / distributed cache stores shared data on the server, not tied to a single user.

_cache.Set("rates", data, TimeSpan.FromMinutes(10));

Summary Table

Dependency Injection (DI) and the IoC Container

Dependency Injection is a design pattern in which an object's dependencies (the services it needs) are supplied to it from outside rather than being created inside the object itself. This implements the principle of Inversion of Control (IoC) — control over object creation and lifetime is inverted from the class to a central container.

ASP.NET Core has a built-in IoC container (IServiceProvider). It is responsible for:

• Creating service instances when requested,
• Resolving and injecting their dependencies recursively,
• Managing each service's lifetime.

Benefits: loose coupling, easier unit testing (mock injection), and centralized configuration.

Service Lifetimes

Registering a Service

Services are registered in Program.cs against the DI container, usually as an interface mapped to an implementation:

builder.Services.AddScoped<IMessageService, EmailService>();

Consuming a Service (Constructor Injection)

The container injects the dependency through the constructor:

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

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

public class HomeController : Controller
{
    private readonly IMessageService _msg;

    // ASP.NET Core injects EmailService automatically
    public HomeController(IMessageService msg)
    {
        _msg = msg;
    }

    public IActionResult Index()
    {
        return Content(_msg.Send("ram@example.com"));
    }
}

The controller depends only on the abstraction IMessageService; the concrete EmailService can be swapped (e.g. with a mock) without changing the controller.

The ASP.NET Core Request Processing Pipeline

When a request reaches an ASP.NET Core app, it flows through a pipeline of middleware components. Each middleware can:

1. Inspect/modify the incoming request,
2. Pass control to the next middleware by calling next(), and
3. Inspect/modify the outgoing response on the way back.

Because control passes forward and then unwinds backward, the pipeline behaves like a series of nested layers ("Russian-doll" model). A middleware may also short-circuit the pipeline by not calling next() (e.g. authentication failure returning 401).

Request ─▶ [Logging] ─▶ [Routing] ─▶ [Auth] ─▶ [Endpoint]
         ◀── Response ◀────────────────────────┘

Middleware

Middleware is software assembled into the pipeline to handle requests and responses. The order of registration in Program.cs defines execution order. Common built-in middleware:

• UseExceptionHandler, UseHttpsRedirection, UseStaticFiles, UseRouting, UseAuthentication, UseAuthorization, MapControllers.

app.UseHttpsRedirection();
app.UseStaticFiles();
app.UseRouting();
app.UseAuthentication();
app.UseAuthorization();
app.MapControllers();

Custom Middleware Component

A simple inline middleware that logs the request path and timing:

app.Use(async (context, next) =>
{
    Console.WriteLine($"Incoming: {context.Request.Path}");
    await next();   // call the next middleware
    Console.WriteLine($"Outgoing: {context.Response.StatusCode}");
});

A reusable convention-based middleware class:

public class RequestLoggingMiddleware
{
    private readonly RequestDelegate _next;

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

    public async Task InvokeAsync(HttpContext context)
    {
        Console.WriteLine($"Request: {context.Request.Method} {context.Request.Path}");
        await _next(context);                 // continue the pipeline
        Console.WriteLine($"Response: {context.Response.StatusCode}");
    }
}

// Register it in Program.cs
app.UseMiddleware<RequestLoggingMiddleware>();

The class must accept a RequestDelegate in its constructor and expose an InvokeAsync(HttpContext) method that calls _next(context) to continue the chain.

struct vs enum in C#

Example:

// struct
struct Point
{
    public int X, Y;
    public Point(int x, int y) { X = x; Y = y; }
}

// enum
enum Day { Sun, Mon, Tue, Wed }   // Sun=0, Mon=1, ...

Point p = new Point(2, 3);
Day today = Day.Mon;

Both are value types stored on the stack (when local), but a struct models complex data with behaviour, whereas an enum simply gives readable names to constant integer values.

Exception Handling in C#

An exception is a runtime error that disrupts the normal flow of a program. C# handles exceptions using the try–catch–finally construct:

• try — encloses code that might throw an exception.
• catch — handles a specific exception type; multiple catch blocks can be ordered from most specific to most general.
• finally — always executes (whether or not an exception occurred), used for cleanup such as closing files/connections.
• throw — raises an exception explicitly.

Example

try
{
    int a = 10, b = 0;
    int result = a / b;          // throws DivideByZeroException
    Console.WriteLine(result);
}
catch (DivideByZeroException ex)
{
    Console.WriteLine("Cannot divide by zero: " + ex.Message);
}
catch (Exception ex)             // general fallback
{
    Console.WriteLine("Error: " + ex.Message);
}
finally
{
    Console.WriteLine("Cleanup done.");
}

Output:

Cannot divide by zero: Attempted to divide by zero.
Cleanup done.

All exceptions derive from System.Exception. Custom exceptions can be created by inheriting from Exception.

Entity Framework vs ADO.NET

Example (EF):

var users = context.Users.Where(u => u.Age > 18).ToList();

Example (ADO.NET):

using var con = new SqlConnection(cs);
con.Open();
var cmd = new SqlCommand("SELECT * FROM Users WHERE Age > 18", con);
var reader = cmd.ExecuteReader();

Summary: EF raises the abstraction level for productivity and maintainability, while ADO.NET gives maximum control and performance at the cost of more manual code. EF internally uses ADO.NET.

Building, Running and Deploying an ASP.NET Core Application

1. Build

Compiles source code into assemblies (DLLs). Using the .NET CLI:

dotnet build

This restores NuGet packages, compiles the project, and produces output in the bin/ folder.

2. Run

Launches the application using the built-in Kestrel web server:

dotnet run

The app listens on a configured port (e.g. https://localhost:5001). During development this enables hot reload and the development environment.

3. Publish (prepare for deployment)

Produces a self-contained, optimized set of files ready to host:

dotnet publish -c Release -o ./publish

The Release configuration optimizes the build; -o specifies the output folder containing the app DLL, dependencies, and static assets.

4. Deploy

The published output can be hosted by:

• IIS on Windows (using the ASP.NET Core Module as a reverse proxy to Kestrel),
• Linux behind Nginx/Apache as a reverse proxy, running as a service,
• Docker container, or
• Cloud platforms such as Azure App Service / AWS.

Deployment can be framework-dependent (target machine needs the .NET runtime) or self-contained (the runtime is bundled with the app).

Validation Controls

Validation controls are mechanisms that ensure user-submitted data meets defined rules (required, format, range, length) before it is processed. In ASP.NET Core, validation is primarily done using Data Annotation attributes on model properties, which drive both server-side and client-side validation.

public class User
{
    [Required(ErrorMessage = "Name is required")]
    public string Name { get; set; }

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

    [Range(18, 60)]
    public int Age { get; set; }
}

Common attributes: [Required], [StringLength], [Range], [EmailAddress], [RegularExpression], [Compare].

Client-side Validation in ASP.NET Core

Client-side validation runs in the browser before the form is submitted, giving instant feedback and reducing server round-trips. ASP.NET Core enables it through:

1. Tag helpers that emit data-val-* HTML attributes from the model's data annotations:

   <input asp-for="Email" />
   <span asp-validation-for="Email"></span>
   

2. jQuery Unobtrusive Validation libraries (jquery.validate.js and jquery.validate.unobtrusive.js) that read those data-val attributes and validate fields on the client.

   <script src="~/lib/jquery-validation/dist/jquery.validate.min.js"></script>
   <script src="~/lib/jquery-validation-unobtrusive/jquery.validate.unobtrusive.min.js"></script>
   

Note: Client-side validation improves UX but is not a security boundary — server-side validation (ModelState.IsValid) must always also be performed because client checks can be bypassed.

appsettings.json and Configuration in ASP.NET Core

appsettings.json is the primary configuration file of an ASP.NET Core application. It stores application settings — such as connection strings, logging levels, and custom options — as JSON key-value pairs, keeping them out of the source code so they can be changed without recompiling.

{
  "ConnectionStrings": {
    "Default": "Server=.;Database=App;Trusted_Connection=True;"
  },
  "Logging": { "LogLevel": { "Default": "Information" } },
  "AppSettings": { "SiteName": "Kekkei" }
}

The Configuration System

ASP.NET Core builds configuration from multiple layered providers, read in order so that later sources override earlier ones:

1. appsettings.json
2. appsettings.{Environment}.json (e.g. appsettings.Development.json)
3. Environment variables
4. Command-line arguments
5. User secrets (development)

All values are exposed through the IConfiguration interface.

Accessing configuration

string cs = builder.Configuration.GetConnectionString("Default");
string name = builder.Configuration["AppSettings:SiteName"];

Strongly-typed via the Options pattern

builder.Services.Configure<AppSettings>(
    builder.Configuration.GetSection("AppSettings"));
// inject IOptions<AppSettings> where needed

Role summary: appsettings.json centralizes environment-specific settings; the configuration system merges all providers and makes them available throughout the app via IConfiguration and the Options pattern.

ViewModel

A ViewModel is a class designed specifically to carry data between a controller and a view. It contains exactly the data (and shape) a particular view needs — often combining fields from several domain models, plus presentation-only properties (dropdown lists, formatted text, validation messages).

public class UserDashboardViewModel
{
    public string FullName { get; set; }          // from User model
    public int OrderCount { get; set; }            // from Order model
    public List<string> RecentItems { get; set; }  // presentation data
}

Model vs ViewModel

Why use a ViewModel?

• Avoids exposing the full entity (security/over-posting).
• Lets a view show data from multiple sources in one object.
• Keeps view-specific validation/formatting separate from domain models, improving maintainability.

Program.cs and the Startup Class in ASP.NET Core

Program.cs

Program.cs is the entry point of an ASP.NET Core application. It creates the web application host, configures services (DI) and the middleware pipeline, and starts the server.

In the modern minimal hosting model (.NET 6+), the separate Startup class is merged into Program.cs:

var builder = WebApplication.CreateBuilder(args);

// ---- Service registration (was ConfigureServices) ----
builder.Services.AddControllersWithViews();
builder.Services.AddScoped<IMessageService, EmailService>();

var app = builder.Build();

// ---- Middleware pipeline (was Configure) ----
app.UseHttpsRedirection();
app.UseStaticFiles();
app.UseRouting();
app.UseAuthorization();
app.MapControllers();

app.Run();   // starts the application

The Startup Class (classic model, .NET Core 3.x / 5)

Before .NET 6, configuration lived in a Startup class with two key methods:

• ConfigureServices(IServiceCollection services) — registers services with the DI container.
• Configure(IApplicationBuilder app, IWebHostEnvironment env) — builds the middleware request pipeline.

public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddControllersWithViews();
    }

    public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
    {
        app.UseRouting();
        app.UseEndpoints(e => e.MapControllers());
    }
}

Summary: Program.cs bootstraps and runs the app; the Startup class (or its equivalent inline code in Program.cs) configures services and the middleware pipeline.

Tag Helpers

Tag Helpers are server-side components in ASP.NET Core that enable C#/server-side logic to participate in creating and rendering HTML elements within Razor views. They look like ordinary HTML attributes (prefixed conventions such as asp-*), making markup cleaner and more HTML-friendly than the older Razor @Html helper syntax, while still being strongly typed and IntelliSense-friendly.

They are enabled in _ViewImports.cshtml:

@addTagHelper *, Microsoft.AspNetCore.Mvc.TagHelpers

Two Examples

1. Anchor Tag Helper (asp-controller, asp-action) — generates URLs from routing:

<a asp-controller="Home" asp-action="Index">Home</a>
<!-- renders: <a href="/Home/Index">Home</a> -->

2. Form / Input Tag Helpers (asp-for) — binds an input to a model property and emits validation attributes:

<form asp-action="Save" method="post">
    <input asp-for="Email" />
    <span asp-validation-for="Email"></span>
    <button type="submit">Save</button>
</form>

Other common tag helpers include asp-validation-summary, asp-route-*, the Label, Image (asp-append-version), and Environment tag helpers.