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

URL Routing in ASP.NET Core

Routing is the mechanism by which an incoming HTTP request URL is matched to an endpoint (a controller action or Razor page) that will handle it, and by which outgoing URLs are generated. The routing middleware (UseRouting and UseEndpoints, or top-level route registration in minimal hosting) inspects the request path and selects the best matching route.

ASP.NET Core MVC supports two styles: conventional routing and attribute routing.

1. Conventional Routing

Routes are defined centrally (usually in Program.cs) as a template pattern that applies to many controllers/actions. It is best for classic CRUD-style apps with uniform URLs.

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

• {controller} and {action} are tokens filled from the URL.
• =Home / =Index give default values, so / maps to HomeController.Index.
• id? is an optional parameter.
• Example: /Products/Details/5 → ProductsController.Details(int id) with id = 5.

2. Attribute Routing

Routes are declared directly on controllers and actions using [Route], [HttpGet], [HttpPost], etc. It gives fine-grained, per-action control and is preferred for Web APIs.

[Route("api/[controller]")]
public class ProductsController : ControllerBase
{
    [HttpGet("{id:int}")]            // GET api/products/5
    public IActionResult Get(int id) => Ok();

    [HttpGet("search/{name}")]       // GET api/products/search/pen
    public IActionResult Search(string name) => Ok();
}

• [controller] token is replaced by the controller name (Products).
• Route constraints like {id:int} restrict matching by type.

Comparison

Both styles can coexist in the same application.

Model Binding and Validation in ASP.NET Core MVC

Model Binding

Model binding is the automatic process that maps data from an HTTP request (route values, query string, form fields, headers, JSON body) onto the parameters or model objects of a controller action. The framework matches request keys to property/parameter names (case-insensitively) and performs type conversion.

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

[HttpPost]
public IActionResult Create(Student s) { /* s is auto-populated */ }

For a form posting Id=5&Name=Ram, the binder creates a Student with those values. Binding sources can be made explicit with attributes such as [FromBody], [FromQuery], [FromRoute], [FromForm].

Validation with Data Annotations

Validation rules are declared as data annotation attributes on model properties (from System.ComponentModel.DataAnnotations):

public class Student {
    [Required(ErrorMessage = "Name is required")]
    [StringLength(50, MinimumLength = 2)]
    public string Name { get; set; }

    [Range(1, 100)]
    public int Age { get; set; }

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

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

Server-side validation

After binding, the framework checks the annotations and populates ModelState. The action verifies it:

if (!ModelState.IsValid)
    return View(s);   // redisplay with errors

This always runs on the server and cannot be bypassed, so it is the authoritative line of defence.

Client-side validation

The same annotations drive client-side validation in views via tag helpers and unobtrusive jQuery validation:

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

Tag helpers emit data-val-* HTML attributes from the annotations; the jquery.validate and jquery.validate.unobtrusive scripts read them and validate in the browser before submitting, giving instant feedback and reducing round-trips.

Summary

The single set of data annotations produces both layers: client-side for fast UX and server-side for security. Client validation can be disabled by the user, so server validation is mandatory.

Structure of the .NET Framework

The .NET Framework is a managed execution platform. Its architecture has two principal layers sitting on top of the operating system:

+-------------------------------------------------+
|  Languages: C#, VB.NET, F#  -> compiled to CIL  |
+-------------------------------------------------+
|  Framework Class Library (FCL / BCL)            |
|  (collections, IO, ADO.NET, ASP.NET, WPF, ...)  |
+-------------------------------------------------+
|  Common Language Runtime (CLR)                  |
|  CTS | CLS | JIT | GC | Security | Loader       |
+-------------------------------------------------+
|  Operating System                               |
+-------------------------------------------------+

Source code is compiled to Common Intermediate Language (CIL/MSIL) plus metadata, packaged into assemblies, and executed by the CLR.

Common Language Runtime (CLR)

The CLR is the execution engine that runs managed code. Its main responsibilities:

• JIT (Just-In-Time) compilation of CIL into native machine code at runtime.
• Memory management and automatic garbage collection.
• Type safety, exception handling, and thread management.
• Code Access Security and verification of metadata. Because all languages compile to CIL, the CLR provides language interoperability — code written in different .NET languages can interact.

Assemblies

An assembly is the fundamental unit of deployment, versioning and security in .NET (a .dll or .exe). It contains:

• CIL code,
• a manifest (assembly name, version, culture, referenced assemblies, public key),
• metadata describing all types and members,
• optional resources. Assemblies may be private (in the app folder) or shared in the Global Assembly Cache (GAC) with a strong name. They are self-describing, which enables reflection.

Common Type System (CTS)

The CTS defines how types are declared, used and managed in the runtime, ensuring that types written in any .NET language share a common definition. It classifies types into:

• Value types — stored on the stack / inline (e.g. int, struct, enum),
• Reference types — stored on the managed heap (e.g. class, string, arrays, delegates). All types ultimately derive from System.Object. The CTS underpins cross-language integration; the related CLS (Common Language Specification) is the subset of CTS rules all languages must honour for interoperability.

Summary

The .NET Framework layers languages and the class library over the CLR; the CLR executes CIL with GC and type safety; assemblies are the deployable units of CIL+metadata; and the CTS guarantees a common, type-safe model across all .NET languages.

TempData, ViewData and ViewBag are mechanisms to pass data from a controller to a view in ASP.NET Core MVC.

• ViewData and ViewBag are two views of the same data and live only for the current request (controller → view). ViewBag is just a dynamic, syntactically simpler wrapper over ViewData.
• TempData survives a redirect (one extra request), so it is ideal for passing messages across a RedirectToAction, e.g. a "Record saved" flash message. Reading a value normally removes it; use TempData.Keep() or Peek() to retain it.

LINQ (Language Integrated Query) is a set of features in C#/.NET that lets you write strongly-typed, declarative queries over data sources (in-memory collections, XML, databases via EF) directly in the language. It provides standard query operators such as Where, Select, OrderBy, GroupBy, and is executed with deferred (lazy) evaluation. The same syntax works across providers (LINQ to Objects, LINQ to Entities, LINQ to XML).

Example — filter a list of integers to keep only even numbers:

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

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

// Equivalent method (fluent) syntax
var evens2 = numbers.Where(n => n % 2 == 0).ToList();

foreach (var n in evens) Console.WriteLine(n);  // 2 4 6 8

Both forms produce {2, 4, 6, 8}. Query syntax is compiled into the method-syntax calls.

Lifecycle of a Request in ASP.NET Core MVC

When an HTTP request arrives, it flows through an ordered middleware pipeline and then the MVC handler:

1. Kestrel / Web server receives the request and hands it to the application.
2. Middleware pipeline runs in order — e.g. exception handling, HTTPS redirection, static files, routing, authentication, authorization. Each middleware may short-circuit or call the next.
3. Routing matches the URL to an endpoint (controller + action) using route templates or attributes.
4. Controller initialization — the controller is instantiated (dependencies injected via DI).
5. Model binding populates action parameters from the request, followed by validation (ModelState).
6. Action filters run (OnActionExecuting → action → OnActionExecuted); authorization and resource filters may run earlier.
7. Action method executes and returns an IActionResult (e.g. ViewResult, JsonResult).
8. Result execution — for a ViewResult the Razor view engine renders the view to HTML; result filters wrap this step.
9. The response travels back out through the middleware pipeline (in reverse) to the client.

Thus the request passes down the middleware pipeline, through routing → model binding → filters → action → result rendering, and the response travels back up the pipeline.

AddSingleton, AddScoped, and AddTransient register service lifetimes in the ASP.NET Core dependency-injection container; they differ in how often a new instance is created.

builder.Services.AddTransient<IEmailService, EmailService>();
builder.Services.AddScoped<IUnitOfWork, UnitOfWork>();
builder.Services.AddSingleton<ICacheService, CacheService>();

• Transient — for lightweight, stateless services.
• Scoped — typical for per-request work such as a DbContext (one shared instance per request).
• Singleton — for shared, thread-safe state like caches or configuration. Note: never inject a Scoped service into a Singleton (captive dependency).

Garbage Collection (GC) in .NET is the CLR's automatic memory-management service. It reclaims memory occupied by managed objects on the heap that are no longer reachable (referenced) by the application, freeing the programmer from manual free/delete and preventing most memory leaks and dangling pointers.

How it works:

• Objects are allocated on the managed heap. When memory pressure rises, the GC runs.
• It uses a mark-and-sweep / mark-and-compact approach: starting from roots (static fields, local variables, CPU registers), it marks all reachable objects; unmarked objects are considered garbage and reclaimed, and the heap is compacted to reduce fragmentation.
• The GC is generational for efficiency:
  • Gen 0 — newly created, short-lived objects (collected most frequently).
  • Gen 1 — survivors of a Gen 0 collection (buffer).
  • Gen 2 — long-lived objects (collected least often).
  • Large objects go to the Large Object Heap (LOH).

Finalization & cleanup: Objects holding unmanaged resources can use a finalizer or implement IDisposable (Dispose / using) for deterministic cleanup, since GC timing of managed memory is non-deterministic.

A partial view is a reusable Razor view (a .cshtml file, often named with a leading underscore such as _ProductCard.cshtml) that renders a portion of a web page rather than a complete page. It does not have its own layout and is meant to be embedded inside other views.

Rendering it:

<partial name="_ProductCard" model="product" />
@* or *@
@await Html.PartialAsync("_ProductCard", product)

When it is used:

• To reuse common markup across multiple views (e.g. a product card, comment block, address form) and follow the DRY principle.
• To break up a large, complex view into smaller, maintainable pieces.
• To render repeated items in a loop with consistent markup.
• To return an HTML fragment for AJAX updates (returning PartialView(...) from an action) without re-rendering the whole page.

Authentication and authorization are two distinct security steps in ASP.NET Core, and authentication always comes first.

• Authentication confirms identity, e.g. validating a username/password or a JWT token and building the user's claims. Middleware: app.UseAuthentication();.
• Authorization decides whether the authenticated user may perform an action, using [Authorize], role checks [Authorize(Roles="Admin")], or policy-based rules. Middleware: app.UseAuthorization(); (must come after UseAuthentication).

A user can be authenticated yet still be denied (not authorized) for a specific resource.

Asynchronous programming lets a program start a long-running or I/O-bound operation (file, network, database) and continue without blocking the calling thread, releasing it to do other work until the operation completes. In C# this is built on the Task-based Asynchronous Pattern using the async and await keywords, which keep the code readable and sequential-looking while running asynchronously.

• async — a modifier on a method that enables the use of await inside it. Such a method typically returns Task, Task<T>, or ValueTask (or void only for event handlers).
• await — applied to an awaitable (a Task); it suspends the method at that point and returns control to the caller until the awaited task finishes, then resumes execution with the result — without blocking the thread.

public async Task<string> GetDataAsync()
{
    using HttpClient client = new();
    // await releases the thread while the request is in flight
    string result = await client.GetStringAsync("https://api.example.com");
    return result;   // resumes here when complete
}

Benefit: improved scalability and responsiveness — server threads aren't held idle waiting on I/O (handling more requests), and UI apps stay responsive. Note await does not create new threads; it efficiently uses the thread pool / I/O completion.

Migrations in Entity Framework Core are the mechanism for evolving the database schema to keep it in sync with the application's model (entity classes / DbContext) over time, while preserving existing data. Instead of manually altering tables, you change your C# model and let EF Core generate the corresponding schema changes.

How they are used:

1. Add a migration — EF compares the current model against the last snapshot and generates a migration class with Up() (apply changes) and Down() (revert) methods:

   dotnet ef migrations add InitialCreate
   

2. Apply the migration to the database, creating/updating tables:

   dotnet ef database update
   

3. As the model changes, add further migrations (AddProductPrice, etc.); each is applied in order and recorded in the __EFMigrationsHistory table so EF knows which have run.
4. Migrations can be rolled back (database update <PreviousMigration>) or scripted (dotnet ef migrations script) for production deployment.

Benefits: version-controlled, incremental, repeatable schema changes; team members and environments stay consistent; no manual SQL needed and existing data is preserved.