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

MVC Design Pattern

MVC (Model–View–Controller) is an architectural pattern that separates an application into three interconnected components, promoting separation of concerns, testability and maintainability.

• Model — Represents the application's data and business logic (domain objects, validation rules, data-access). It knows nothing about the UI.
• View — The presentation layer (UI). In ASP.NET Core these are typically Razor (.cshtml) files that render HTML using data supplied by the controller.
• Controller — Handles incoming HTTP requests, processes user input, invokes the model and selects a view to return as the response.

Flow: A request hits the Controller → the Controller updates/queries the Model → the Controller passes data to the View → the View renders the response to the browser.

  Browser ──request──▶ Controller ──▶ Model (data/logic)
     ▲                    │              │
     │                    ▼              │
     └────HTML────────  View  ◀──────────┘

ASP.NET Core Framework — Architecture & Design Principles

ASP.NET Core is a cross-platform, open-source, high-performance framework for building web apps and APIs that runs on Windows, Linux and macOS.

Architecture (layered):

┌──────────────────────────────────────────────┐
│  Application (MVC Controllers / Razor / APIs)  │
├──────────────────────────────────────────────┤
│  Middleware Pipeline (Auth, Routing, Static,   │
│  Exception, MVC) — request flows in & out      │
├──────────────────────────────────────────────┤
│  Kestrel Web Server (cross-platform)           │
├──────────────────────────────────────────────┤
│  .NET Runtime / Reverse proxy (IIS, Nginx)     │
└──────────────────────────────────────────────┘

A request enters through Kestrel, passes through a configurable middleware pipeline (each middleware can handle the request and call next()), reaches the routing/MVC middleware that dispatches to a controller action, and the response travels back out through the same pipeline.

Key design principles:

1. Modularity / Middleware pipeline — Cross-cutting concerns (logging, auth, routing) are composed as ordered middleware components.
2. Built-in Dependency Injection (DI) — Services are registered in a container and injected via constructors, enabling loose coupling and testability.
3. Cross-platform & open-source — Runs anywhere the .NET runtime exists.
4. Unified framework — MVC, Web API and Razor Pages share one programming model.
5. Configuration & Environment-based — Flexible configuration (appsettings.json, env variables) and environment-aware behavior (Development/Production).
6. High performance & lightweight — Kestrel server and a self-contained, modular runtime.

Thus ASP.NET Core implements the MVC pattern on top of a middleware-based, DI-driven, cross-platform pipeline.

CRUD with Entity Framework Core (ASP.NET Core)

EF Core is an ORM. We define a model, a DbContext, and use it to insert, update, delete and read data.

Model & DbContext

public class Student
{
    public int Id { get; set; }
    public string Name { get; set; }
    public int Age { get; set; }
}

public class AppDbContext : DbContext
{
    public AppDbContext(DbContextOptions<AppDbContext> options) : base(options) { }
    public DbSet<Student> Students { get; set; }
}

The context is registered in Program.cs:

builder.Services.AddDbContext<AppDbContext>(o =>
    o.UseSqlServer(builder.Configuration.GetConnectionString("Default")));

Insert (Create)

public async Task Create(Student s)
{
    _context.Students.Add(s);
    await _context.SaveChangesAsync();
}

Read

public async Task<List<Student>> GetAll() =>
    await _context.Students.ToListAsync();

public async Task<Student?> GetById(int id) =>
    await _context.Students.FindAsync(id);

Update

public async Task Update(Student s)
{
    _context.Students.Update(s);        // or modify a tracked entity
    await _context.SaveChangesAsync();
}

Delete

public async Task Delete(int id)
{
    var s = await _context.Students.FindAsync(id);
    if (s != null)
    {
        _context.Students.Remove(s);
        await _context.SaveChangesAsync();
    }
}

Note: _context is the injected AppDbContext. SaveChangesAsync() commits the tracked changes to the database; EF Core tracks entity states (Added, Modified, Deleted) and generates the corresponding SQL.

State Management in Stateless HTTP

HTTP is stateless — each request is independent and the server retains no memory of previous requests. To preserve user/application data across requests, ASP.NET Core uses several state management techniques, broadly client-side and server-side.

Client-side techniques

1. Cookies — Small key–value data stored in the browser and sent with each request.

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

2. Query strings — Data passed in the URL: /products?id=10. Read via Request.Query["id"]. Limited size, visible to user.
3. Hidden form fields — Values posted back with a form, not displayed to the user.

Server-side techniques

4. Session — Per-user data stored on the server, keyed by a session cookie.

   // Program.cs
   builder.Services.AddSession();
   app.UseSession();
   // usage
   HttpContext.Session.SetString("User", "Ram");
   var u = HttpContext.Session.GetString("User");
   

5. TempData — Stores data for the next request only (commonly via session); useful for redirect messages.

   TempData["Message"] = "Saved successfully";
   

6. Application/Cache state — Shared data across all users via IMemoryCache or a distributed cache (Redis).
7. Database — Persistent state stored permanently (e.g., user profiles via EF Core).

Summary table

Thus, although HTTP itself is stateless, ASP.NET Core layers these mechanisms on top to simulate stateful behavior.

struct vs enum in C#

Both are value types, but serve different purposes.

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

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

Summary: a struct models a value object with fields and methods, while an enum defines a fixed list of named constant values for readability and type safety.

Exception Handling in C#

An exception is a runtime error. C# handles exceptions using the try–catch–finally construct, preventing abnormal program termination and allowing graceful recovery.

• try — encloses code that might throw an exception.
• catch — handles a specific exception type; multiple catch blocks are allowed (most specific first).
• finally — always executes (whether or not an exception occurred), used for cleanup.
• 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)
{
    Console.WriteLine("Error: " + ex.Message);
}
finally
{
    Console.WriteLine("Cleanup done.");   // always runs
}

Output:

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

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

Entity Framework vs ADO.NET

// EF Core
var students = _context.Students.Where(s => s.Age > 18).ToList();

// ADO.NET
var cmd = new SqlCommand("SELECT * FROM Students WHERE Age > 18", conn);
var reader = cmd.ExecuteReader();

Summary: EF offers higher abstraction and faster development, while ADO.NET offers more control and better raw performance.

Build, Run and Deploy an ASP.NET Core Application

1. Build

Compile the source into intermediate language and produce assemblies.

dotnet build

This restores NuGet packages and outputs DLLs to bin/.

2. Run

Run the app locally using the built-in Kestrel server.

dotnet run

The app listens on a local port (e.g., https://localhost:5001) and can be tested in a browser. During development, Development environment and hot-reload (dotnet watch run) may be used.

3. Publish (prepare for deployment)

Produce an optimized, self-contained or framework-dependent set of deployable files.

dotnet publish -c Release -o ./publish

The publish folder contains the app DLLs, dependencies and appsettings.json.

4. Deploy

Host the published output. Common options:

• IIS / Nginx / Apache as a reverse proxy in front of Kestrel.
• Cloud — Azure App Service, AWS, Docker container.
• Self-host — run dotnet MyApp.dll on the server.

Configure the production environment (ASPNETCORE_ENVIRONMENT=Production), connection strings and HTTPS, then start the process behind the reverse proxy.

Summary flow: dotnet build → dotnet run (test) → dotnet publish → host on a server/cloud behind a reverse proxy.

Validation Controls & Client-side Validation in ASP.NET Core

Validation ensures user-entered data meets defined rules before processing. ASP.NET Core uses Data Annotation attributes on model properties (rather than the old Web Forms validation controls), and these drive both server- and client-side validation.

Common validation attributes

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

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

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

    [StringLength(10, MinimumLength = 6)]
    public string Password { get; set; }
}

Others: [Compare], [RegularExpression], [Phone].

Client-side validation

Client-side validation runs in the browser before the form is submitted, giving instant feedback and reducing server round-trips. ASP.NET Core implements it using unobtrusive validation built on jQuery Validation.

In the Razor view, tag helpers emit the validation attributes:

<form asp-action="Register">
    <input asp-for="Email" />
    <span asp-validation-for="Email"></span>
</form>
@section Scripts {
    <partial name="_ValidationScriptsPartial" />
}

The asp-for / asp-validation-for tag helpers render data-val-* HTML attributes, and the jQuery unobtrusive scripts read them to validate fields on the client.

Note: Client-side validation improves UX but is not a security boundary — the same Data Annotations are re-validated on the server (ModelState.IsValid).

Role of appsettings.json and Configuration in ASP.NET Core

appsettings.json is the primary JSON-based configuration file in an ASP.NET Core app. It stores application settings such as connection strings, logging levels, and custom options — keeping them out of the compiled code so they can change without recompiling.

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

The Configuration system

ASP.NET Core has a layered configuration provider model. Settings are read from multiple sources and merged, with later sources overriding earlier ones:

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

This lets the same app behave differently per environment (Development vs Production).

Accessing configuration

// Direct access
var conn = builder.Configuration.GetConnectionString("Default");
int size = builder.Configuration.GetValue<int>("AppSettings:PageSize");

// Strongly-typed binding (Options pattern)
builder.Services.Configure<AppSettings>(
    builder.Configuration.GetSection("AppSettings"));

Summary: appsettings.json centralizes configuration; the configuration system layers and overrides it by environment and injects values via IConfiguration or the strongly-typed Options pattern.

ViewModel vs Model

Model — A class that represents the application's domain/data and business logic, usually mapped to a database table via EF Core (e.g., a Student entity). It is shared across the data and business layers.

ViewModel — A class designed specifically for a particular view. It holds exactly the data the view needs for display or input, often combining fields from multiple models or adding view-specific/validation properties. It contains no business logic and is not tied to the database.

Difference

Example

// Models
public class Student { public int Id; public string Name; }
public class Course  { public int Id; public string Title; }

// ViewModel combining data for one view
public class StudentDashboardViewModel
{
    public string StudentName { get; set; }
    public List<Course> EnrolledCourses { get; set; }
    public int TotalCredits { get; set; }   // view-specific computed field
}

Summary: Use a ViewModel to decouple the view from your domain models, exposing only the data the view needs and avoiding over-posting or leaking entity internals.

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

Program.cs

Program.cs is the application entry point. It creates the host, configures services and the middleware pipeline, and runs the app. In the modern minimal hosting model (ASP.NET Core 6+), Program.cs does everything (the separate Startup class is no longer required):

var builder = WebApplication.CreateBuilder(args);

// 1. Register services (Dependency Injection container)
builder.Services.AddControllersWithViews();
builder.Services.AddDbContext<AppDbContext>(/* ... */);

var app = builder.Build();

// 2. Configure the middleware pipeline
app.UseStaticFiles();
app.UseRouting();
app.UseAuthorization();
app.MapControllerRoute("default", "{controller=Home}/{action=Index}/{id?}");

app.Run();

Startup class (classic model, ASP.NET Core 3.x–5)

Before the minimal model, configuration was split into a Startup class with two methods:

• ConfigureServices(IServiceCollection services) — registers application services into the DI container (e.g., AddControllersWithViews, AddDbContext).
• Configure(IApplicationBuilder app, IWebHostEnvironment env) — builds the middleware/request pipeline (UseRouting, UseAuthentication, UseEndpoints).

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

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

Here Program.cs simply referenced it: webBuilder.UseStartup<Startup>();

Summary: Program.cs is the entry point that bootstraps and runs the host. The Startup class (older versions) separated service registration and pipeline configuration into ConfigureServices and Configure; in ASP.NET Core 6+ both responsibilities are merged into Program.cs.

Tag Helpers in ASP.NET Core

Tag Helpers are server-side components that enable C#/server code to participate in creating and rendering HTML elements in Razor (.cshtml) views. They look like normal HTML attributes (asp-*), making views cleaner and more HTML-like than the older Razor @Html helpers, while remaining strongly typed.

• Processed on the server, they generate the final HTML sent to the browser.
• Enabled via @addTagHelpers (default in _ViewImports.cshtml).

Two examples

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

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

2. Input/Label Tag Helper (asp-for) — binds a form field to a model property, generating the name, id and validation attributes:

<label asp-for="Email"></label>
<input asp-for="Email" />
<!-- renders: <input type="text" id="Email" name="Email" ... /> -->

Other common ones: Form Tag Helper (asp-action), Validation Tag Helper (asp-validation-for), Environment Tag Helper.

Summary: Tag Helpers bridge server-side model data and HTML, producing strongly-typed, maintainable markup.