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

Model Binding and Validation in ASP.NET Core MVC

Model Binding

Model binding is the process by which ASP.NET Core MVC automatically maps incoming HTTP request data (form fields, route values, query strings, headers, and JSON/XML request bodies) to the parameters of an action method or to the properties of a model object.

For example, given:

public IActionResult Create(Student student) { ... }

the binder inspects each property of Student (Name, Age, Email, ...) and populates it from request data whose name matches the property name. The binder searches data sources in this default order: Form values → Route values → Query string. Binding source attributes ([FromBody], [FromQuery], [FromRoute], [FromForm], [FromHeader]) override the default order.

Validation

After binding, MVC validates the bound model against the rules declared on it. The result of validation is stored in ModelState. The action checks it via:

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

Data Annotations

Data annotations are attributes from System.ComponentModel.DataAnnotations applied to model properties to declare validation rules:

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

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

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

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

Server-side validation

When the form posts back, the binder applies the annotation rules on the server and fills ModelState with any errors. The action then checks ModelState.IsValid and re-renders the view if invalid. Server-side validation is mandatory because client-side checks can be bypassed.

Client-side validation

The same data annotations also drive unobtrusive client-side validation. When a Razor view uses tag helpers such as asp-for and asp-validation-for, the framework emits HTML5 data-val-* attributes derived from the annotations:

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

The jQuery Validation and jQuery Unobtrusive Validation scripts read these attributes and validate the form in the browser before submission, giving instant feedback and reducing round-trips. This is enabled by including _ValidationScriptsPartial.cshtml.

Summary

Model binding fills the model from the request; data annotations declare rules once and are enforced both on the client (via emitted data-val-* attributes + jQuery) for fast feedback and on the server (via ModelState) for security.

Structure of the .NET Framework

The .NET Framework is a managed software platform for building and running Windows applications. Its two principal components are the Common Language Runtime (CLR) and the .NET Framework Class Library (FCL/BCL), sitting above the operating system.

+------------------------------------------------+
|  Applications (Console, WinForms, ASP.NET...)  |
+------------------------------------------------+
|  .NET Framework Class Library (BCL/FCL)        |
+------------------------------------------------+
|  Common Language Runtime (CLR)                 |
+------------------------------------------------+
|  Operating System                              |
+------------------------------------------------+

Source code (C#, VB.NET, F#) is compiled by a language compiler into Common Intermediate Language (CIL/MSIL) plus metadata, packaged as an assembly. At run time the CLR's JIT (Just-In-Time) compiler translates CIL into native machine code.

Common Language Runtime (CLR)

The CLR is the execution engine (virtual machine) of .NET. It provides managed-execution services:

• JIT compilation of CIL to native code.
• Automatic memory management via the Garbage Collector (GC).
• Type safety and code verification.
• Exception handling and security (Code Access Security).
• Thread management and interoperability with unmanaged code.

Code that runs under the CLR is called managed code.

Assemblies

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

• CIL code,
• a manifest (assembly metadata: name, version, culture, referenced assemblies, security permissions),
• type metadata describing every type, and
• optional resources (images, strings).

Assemblies can be private (in the application folder) or shared (strong-named, placed in the Global Assembly Cache / GAC). They are self-describing because they carry their own metadata.

Common Type System (CTS)

The CTS defines how types are declared, used, and managed in the runtime, ensuring that types written in different .NET languages can interoperate. It classifies all types into two categories:

• Value types — store data directly on the stack (e.g. int, struct, enum).
• Reference types — store a reference to data on the managed heap (e.g. class, string, arrays).

The CTS guarantees a common set of rules (e.g. every type derives from System.Object), and the related Common Language Specification (CLS) defines a subset of features that all languages must support to be cross-language compatible.

Conclusion

The .NET Framework layers the CLR (execution engine) and the class library over the OS. Assemblies package managed CIL code with self-describing metadata, while the CTS provides a unified type model that enables seamless cross-language interoperability.

Web API and RESTful Services in ASP.NET Core

What is a Web API?

A Web API is a web service that exposes application functionality and data over HTTP so that different clients (browsers, mobile apps, other servers) can consume it programmatically. It returns data (typically JSON or XML) rather than HTML pages. A RESTful Web API follows the REST architectural style: it is stateless, uses resource URIs (e.g. /api/products/5), and maps HTTP verbs to operations:

Creating a RESTful Web API in ASP.NET Core

A controller derives from ControllerBase and is decorated with [ApiController] and a route:

[ApiController]
[Route("api/[controller]")]
public class ProductsController : ControllerBase
{
    private readonly AppDbContext _db;
    public ProductsController(AppDbContext db) => _db = db;

    [HttpGet]
    public ActionResult<IEnumerable<Product>> GetAll() => _db.Products.ToList();

    [HttpGet("{id}")]
    public ActionResult<Product> Get(int id)
    {
        var p = _db.Products.Find(id);
        return p == null ? NotFound() : Ok(p);
    }

    [HttpPost]
    public ActionResult<Product> Create(Product p)
    {
        _db.Products.Add(p);
        _db.SaveChanges();
        return CreatedAtAction(nameof(Get), new { id = p.Id }, p);
    }

    [HttpPut("{id}")]
    public IActionResult Update(int id, Product p) { /* ... */ return NoContent(); }

    [HttpDelete("{id}")]
    public IActionResult Delete(int id) { /* ... */ return NoContent(); }
}

In Program.cs the services are registered:

builder.Services.AddControllers();
...
app.MapControllers();

The [ApiController] attribute enables automatic model validation (returns HTTP 400 on invalid model), binding-source inference, and proper HTTP status responses (Ok, NotFound, CreatedAtAction).

Consuming the Web API from a client

A .NET client uses HttpClient:

using var client = new HttpClient { BaseAddress = new Uri("https://localhost:5001/") };

// GET
var products = await client.GetFromJsonAsync<List<Product>>("api/products");

// POST
var resp = await client.PostAsJsonAsync("api/products", new Product { Name = "Pen" });

Browser clients consume it with fetch / XMLHttpRequest (AJAX), parsing the returned JSON. The response status code communicates success or failure (200, 201, 404, 400, etc.).

Summary

A Web API exposes data over HTTP. In ASP.NET Core it is built with [ApiController] controllers that map HTTP verbs to CRUD operations and return JSON, and it is consumed by clients such as HttpClient or browser fetch.

struct vs enum in C#

Both are value types stored on the stack (or inline), but a struct models a small object with multiple members and behaviour, whereas an enum simply gives readable names to a set of constant integral values.

struct Point { public int X; public int Y; }
enum Direction { North, East, South, West }  // 0,1,2,3

Exception Handling in C#

An exception is a runtime error that disrupts normal program flow. C# handles exceptions with the try–catch–finally construct, which lets a program detect, respond to, and recover from errors gracefully instead of crashing.

• try — encloses code that may throw an exception.
• catch — handles a specific exception type; multiple catch blocks can be ordered from most to least specific.
• finally — always executes (whether or not an exception occurred), used to release resources.
• throw — raises an exception explicitly.

All exceptions derive from System.Exception.

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)             // generic fallback
{
    Console.WriteLine("Error: " + ex.Message);
}
finally
{
    Console.WriteLine("Cleanup done.");  // always runs
}

Output:

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

This prevents the program from terminating abnormally and allows controlled error reporting and resource cleanup.

Entity Framework vs ADO.NET

ADO.NET gives fine-grained, high-performance control using explicit SQL and connected/disconnected objects. Entity Framework raises the abstraction level: developers manipulate strongly-typed objects and write LINQ, while EF translates them into SQL and tracks changes — improving productivity at a small performance cost.

// ADO.NET
var cmd = new SqlCommand("SELECT * FROM Products WHERE Id=@id", conn);

// Entity Framework (LINQ)
var product = db.Products.FirstOrDefault(p => p.Id == id);

Building, Running and Deploying an ASP.NET Core Application

1. Build

The project is compiled from source into a managed assembly (.dll).

• Using the CLI: dotnet build — restores NuGet packages and compiles the project, producing output in bin/Debug/netX.0/.
• (dotnet restore is run implicitly to download dependencies.)

2. Run

The application is executed on the Kestrel web server (the cross-platform default).

• dotnet run — builds (if needed) and launches the app; it listens on the URLs configured in launchSettings.json / appsettings.json (e.g. https://localhost:5001).
• In development this enables hot features and the Developer Exception Page.

3. Publish (prepare for deployment)

• dotnet publish -c Release -o ./publish — compiles in Release mode and copies the app, its dependencies, static files (wwwroot), and appsettings.json into a self-contained output folder ready to host.
• Can be framework-dependent (requires .NET runtime on the host) or self-contained (bundles the runtime).

4. Deploy / Host

The published output is hosted by one of:

• IIS on Windows (with the ASP.NET Core Module forwarding requests to Kestrel),
• Nginx/Apache as a reverse proxy on Linux,
• Docker containers, or
• a cloud service such as Azure App Service.

Summary

dotnet build → dotnet run (test locally) → dotnet publish -c Release → copy the published folder to the host (IIS / Nginx / Docker / Azure) where Kestrel serves the app, usually behind a reverse proxy.

Validation Controls and Client-Side Validation in ASP.NET Core

Validation controls

In ASP.NET Core MVC/Razor, validation is driven by data annotation attributes on model properties together with tag helpers in the view (rather than the old Web Forms server controls). The key building blocks are:

• Data annotations — [Required], [StringLength], [Range], [RegularExpression], [EmailAddress], [Compare] — declare the rules.
• asp-validation-for tag helper — displays the error message for one property.
• asp-validation-summary tag helper — displays a summary of all validation errors.

public class User
{
    [Required] public string Name { get; set; }
    [EmailAddress] public string Email { get; set; }
}

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

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 through unobtrusive validation:

1. The tag helpers emit HTML5 data-val-* attributes (e.g. data-val-required, data-val-email) generated from the data annotations.
2. The jQuery Validation and jQuery Unobtrusive Validation libraries read those attributes and validate fields on the client.

These scripts are added by including the partial view:

@section Scripts { <partial name="_ValidationScriptsPartial" /> }

Note: Client-side validation improves user experience but can be bypassed, so the same annotations are always re-validated on the server via ModelState.IsValid.

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

appsettings.json

appsettings.json is the standard JSON configuration file for an ASP.NET Core application. It stores application settings — such as connection strings, logging levels, and custom options — outside the code, so values can be changed without recompiling.

{
  "ConnectionStrings": {
    "Default": "Server=.;Database=ShopDb;Trusted_Connection=True;"
  },
  "Logging": { "LogLevel": { "Default": "Information" } },
  "AppSettings": { "SiteName": "My Shop" }
}

The Configuration system

ASP.NET Core has a flexible, layered configuration system that reads settings from multiple providers and merges them into a single IConfiguration object. Common providers (read in order, later overriding earlier):

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

This layering lets the same app use different settings per environment (Development, Staging, Production).

Accessing configuration

// Direct access
string conn = builder.Configuration.GetConnectionString("Default");
string site = builder.Configuration["AppSettings:SiteName"];

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

Injected anywhere with IConfiguration or IOptions<T>.

Summary

appsettings.json externalises configuration data; the configuration system layers it with environment-specific files, environment variables, and command-line args into IConfiguration, which is accessed directly or via the strongly-typed Options pattern.

ViewModel vs Model

What is a ViewModel?

A ViewModel is a class created specifically to shape and carry data for a particular view. It contains exactly the data (and presentation-specific properties) a view needs — often combining fields from several domain models, plus extra items like dropdown lists, flags, or formatted values.

public class OrderViewModel
{
    public string CustomerName { get; set; }   // from Customer model
    public List<Product> Items { get; set; }    // from Product model
    public decimal Total { get; set; }          // computed for display
    public List<SelectListItem> PaymentOptions { get; set; }
}

How it differs from a Model

Benefit

Using a ViewModel decouples the UI from domain entities, avoids exposing or over-binding sensitive model fields, and keeps views clean and strongly typed.

Startup Class and Program.cs in ASP.NET Core

Program.cs

Program.cs is the entry point of an ASP.NET Core application; it contains the Main method that builds and runs the host. The host sets up the web server (Kestrel), configuration, logging, and dependency injection container.

In the minimal hosting model (ASP.NET Core 6+), Program.cs does everything in one file:

var builder = WebApplication.CreateBuilder(args);

// Register services (DI)
builder.Services.AddControllersWithViews();
builder.Services.AddDbContext<AppDbContext>();

var app = builder.Build();

// Configure middleware pipeline
if (!app.Environment.IsDevelopment())
    app.UseExceptionHandler("/Home/Error");
app.UseStaticFiles();
app.UseRouting();
app.UseAuthorization();
app.MapControllerRoute("default", "{controller=Home}/{action=Index}/{id?}");

app.Run();

Startup class

In the older (pre-.NET 6) model, the Startup class held the same responsibilities through two methods:

• ConfigureServices(IServiceCollection services) — registers application services in the dependency-injection container (e.g. AddControllers, AddDbContext).
• Configure(IApplicationBuilder app, IWebHostEnvironment env) — builds the middleware (request) pipeline with app.Use... calls (routing, static files, authentication, endpoints).

Relationship

The two methods of Startup correspond exactly to the two phases now written in Program.cs: service registration (builder.Services...) and middleware configuration (app.Use...). The minimal model in .NET 6+ merges Program.cs and Startup into a single streamlined file, though the Startup pattern is still valid and widely seen in exam questions.

Tag Helpers in ASP.NET Core

What are tag helpers?

Tag helpers are server-side components that participate in rendering Razor (.cshtml) views by attaching to HTML elements or attributes and generating/modifying the emitted HTML. They let developers write clean, HTML-like markup (with asp-* attributes) instead of C# Razor code blocks (@Html helpers), while still benefiting from server-side processing, IntelliSense, and strong typing. Tag helpers are enabled with @addTagHelpers in _ViewImports.cshtml.

Two examples

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

   <a asp-controller="Products" asp-action="Details" asp-route-id="5">View</a>
   <!-- renders: <a href="/Products/Details/5">View</a> -->
   

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

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

Other common tag helpers include the Form (asp-action), Select (asp-items), and Environment tag helpers.

Benefit

Tag helpers keep markup readable and HTML-friendly while integrating model binding, routing, and validation on the server.