This JSON is basically a serialization of our entity, with some built-in conventions such as;
CamelCase instead of PascalCase: We got levelName instead of LevelName and son, meaning that all our PascalCase .NET class names and properties will be automatically converted into camelCase when they are serialized to JSO,
No indentation and no line feed / carriage return (LF/CR): Everything is stacked within a single line of text.
These conventions are the default options set by .NET core when dealing with JSON outputs.
To change the default behavior for readability and no PascalCase to CamelCase switching, add these to Program.cs file;
builder.Services.AddControllersWithViews()
.AddJsonOptions(options =>
{
// set this option to TRUE to indent hte JSON output
options.JsonSerializerOptions.WriteIndented = true;
// set this option to NULL to use PascalCase instead of camelCase (default)
options.JsonSerializerOptions.PropertyNamingPolicy = null;
});
Let’s get our hands in some code. This web app will act as a monitoring and reporting service that will check the health status of a target server.
We are going to use Micorosft.AspNetCore.Diagnositcs.HealthChecks package, a built-in feature of the .NET Core framework. This package is meant to be used to allow a monitoring service to check the status of another running service.
Add app.UseHalthChecks middleware in Program.cs file;
This middleware will create a server-side route for the health checks. Note that we have added this middleware before Endpoints so that this new route won’t be overriden by the general-purpose Controller route pattern.
Keep in mind, when we run application it uses two ports; one for server side and second one for angular side (in our case it’s 7031). For angular it creates a proxy and re-direct users there (in this case 44488).
If we run our application, we can see our system is healthy.
The system is healthy because we haven’t defined any checks yet.
Let’s add an Internet Control Message Protocol (ICMP) AKA Ping. PING request is a basic way to check the presence and therefore availability, of a server that we know we should be able to reach within a LAN / WAN connection.
In a nutshell, it works in following way; the machine that performs the PING sends one or more ICMP echo request packets to the target host and waits for a reply; if it receives it, it reports the round-trip time of the whole task; otherwise, it time outs and reports a “host not reachable” error.
The “host not reachable” error can be due to a number of possible reasons;
The target host is not available
The target host is available, but actively refuses TCP/IP connections of any kind
The target host is available and accepts TCP/IP incoming conections, but it has been configured to explicitly refuse ICMP requests and/or not send ICMP echo replies back.
The target host is available and properly configured to accept ICMP requests and send echo replies back, but the connection is very slow or hindered by unknown reasons (performance, heavy load etc), so the round-trip time takes too long, or even times out.
So what could be the possible outcomes of our implementation;
Healthy: We can consider the host Healthy whenever the PING succeeded with no errors and timeouts.
Degraded: We can consider the host Degraded whenever the PING succeeded, but the round-trip takes too long.
Unhealthy: We can consider the host Unhealthy whenever the PING failed, that is, the check times out before any reply.
public class PingHealthCheck : IHealthCheck
{
private string Host = "www.does-not-exist.com";
private int Timeout = 300;
public async Task<HealthCheckResult> CheckHealthAsync(HealthCheckContext context, CancellationToken cancellationToken = default)
{
try
{
using (var ping = new Ping())
{
var reply = await ping.SendPingAsync(Host);
switch (reply.Status)
{
case IPStatus.Success:
return (reply.RoundtripTime > Timeout) ? HealthCheckResult.Degraded() : HealthCheckResult.Healthy();
default:
return HealthCheckResult.Unhealthy();
}
}
}
catch (Exception ex)
{
return HealthCheckResult.Unhealthy();
}
}
}
Add PingHealthCheck to the pipeline by modifying Program.cs file;
So we are getting a response. that’s great, it works. Three are 3 major flaws;
Hardcoded values: The Host and the Timeout variables should be passed as parameters
Uninformative response: Healthy and Unhealthy are not that great, we should create a better output message
Untyped output: The current response is being sent in plain text, if we want to fetch it with Angular, a JSON content-type be better.
public class PingHealthCheck : IHealthCheck
{
private string Host { get; set; }
private int Timeout { get; set; }
public PingHealthCheck(string host, int timeout)
{
Host = host;
Timeout = timeout;
}
public async Task<HealthCheckResult> CheckHealthAsync(HealthCheckContext context, CancellationToken cancellationToken = default)
{
try
{
using (var ping = new Ping())
{
var reply = await ping.SendPingAsync(Host);
switch (reply.Status)
{
case IPStatus.Success:
var msg = $"ICMP to {Host} took {reply.RoundtripTime} ms.";
return (reply.RoundtripTime > Timeout) ? HealthCheckResult.Degraded(msg) : HealthCheckResult.Healthy(msg);
default:
var err = $"ICMP to {Host} failed: {reply.Status}";
return HealthCheckResult.Unhealthy(err);
}
}
}
catch (Exception ex)
{
var err = $"ICMP to {Host} failed: {ex.Message}";
return HealthCheckResult.Unhealthy(err);
}
}
}
Update middleware in Program.cs file so that we can call it programmatically;
builder.Services.AddHealthChecks()
.AddCheck("PING_01", new PingHealthCheck("www.msn.com", 100))
.AddCheck("PING_02", new PingHealthCheck("www.google.com", 100))
.AddCheck("PING_03", new PingHealthCheck("www.does-not-exist.com", 100));
The reason is obvious, if one of them failed the whole stack will be failed. The last one in our example is failure. We can avoid this sum behavior by implementing the resolution of third flaw (as mentioned before): JSON-structured output message.
Add a new class in project root, CustomHealthCheckOptions;
public class CustomHealthCheckOptions : HealthCheckOptions
{
public CustomHealthCheckOptions() : base()
{
var jsonSerializerOptions = new JsonSerializerOptions()
{
WriteIndented = true
};
ResponseWriter = async (c, r) =>
{
c.Response.ContentType = MediaTypeNames.Application.Json;
c.Response.StatusCode = StatusCodes.Status200OK;
var result = JsonSerializer.Serialize(new
{
checks = r.Entries.Select(e => new
{
name = e.Key,
responseTime = e.Value.Duration.TotalMilliseconds,
status = e.Value.Status.ToString(),
description = e.Value.Description
}),
totalStatus = r.Status,
totalResponseTime = r.TotalDuration.TotalMilliseconds,
}, jsonSerializerOptions);
await c.Response.WriteAsync(result);
};
}
}
Modify Program.cs file;
app.UseHealthChecks("/hc", new CustomHealthCheckOptions());
Run the application and here is expected output;
{
"checks": [
{
"name": "PING_01",
"responseTime": 78.6889,
"status": "Healthy",
"description": "ICMP to www.msn.com took 12 ms."
},
{
"name": "PING_02",
"responseTime": 62.3402,
"status": "Healthy",
"description": "ICMP to www.google.com took 14 ms."
},
{
"name": "PING_03",
"responseTime": 144.9184,
"status": "Unhealthy",
"description": "ICMP to www.does-not-exist.com failed: An exception occurred during a Ping request."
}
],
"totalStatus": 0,
"totalResponseTime": 181.1726
}
Each and every check is properly documented, as well as the total outcome data, in a structured JSON object. This is just what we need to feed some Angular Components.
We are going to learn how to pass data in ASP.NET Core using Model binding for HTTP GET request. The GET method is generally used for less complex and non-sensitive data transfer.
The model binding refers to converting the HTTP request data (from the query string or form collection) to an action methods parameter. These parameters can be of primitive type or complex type.
We will be using Visual Studio 2022 for this test. We are going to use following modal in this exercise;
public class Project
{
public int Id { get; set; }
public ProjectIdentity? ProjectIdentity { get; set; }
}
public class ProjectIdentity
{
public int Id { get; set; }
public int ModificationId { get; set; }
}
First test case – Primitive Type
The HTTP GET request embeds data into a query string. MVC framework automatically converts a query string to the action method parameters provided their names are matching.
For example;
Create a new project using MVC template in Visual Studio. Don’t make any changes to the default; Make sure jQuery works. Add following to index.cshtml page;
Create Sample class with onclick event and an instance of Sample class in jQuery ready function;
class Sample
{
constructor() { }
OnButtonClick()
{
$.ajax({
type: 'GET',
url: "@Url.Action("GetInfoPrimitive", "Home")",
dataType: 'json',
contentType: 'application/json',
data: {"ProjectId":"1"},
success: function (result) {
alert('Data submitted.');
console.log(result);
},
failure: function (result) {
alert("Something went wrong. Plese contact System Administrator.");
console.log(result);
}
});
}
}
Our complete jQuery function would look like this;
@section scripts {
<script type="text/javascript">
var sample;
$(function () {
console.log("ready!");
sample = new Sample();
});
class Sample
{
constructor() { }
OnButtonClick()
{
$.ajax({
type: 'GET',
url: "@Url.Action("GetInfoPrimitive", "Home")",
dataType: 'json',
contentType: 'application/json',
data: {"ProjectId":"1"},
success: function (result) {
alert('Data submitted.');
console.log(result);
},
failure: function (result) {
alert("Something went wrong. Plese contact System Administrator.");
console.log(result);
}
});
}
}
</script>
}
We need to create a method on server side that will be called by Ajax method;
[HttpGet]
public int GetInfoPrimitive(int projectId)
{
Console.WriteLine($"Incoming parameter value: {JsonSerializer.Serialize(projectId)}");
return projectId;
}
Put a breakpoint on “return projectId” line. Run the app and click on Get Request button.
The debugger should stop on “return projectId” statement and console results would be like this;
Click continue to resume the application. There is no problem with this method.
Second test case – Binding to Complex Type
Model binding also works on complex types. It will automatically convert the input fields data on the view to the properties of a complex type parameter of an action method in HttpGet request if the properties’ names match with the fields on the view.
For example;
The only change in earlier example code is that we are going to pass an object to the view and would use that object to submit Get request;
public IActionResult Index()
{
var request = new ProjectIdentity();
return View(request);
}
[HttpGet]
public ProjectIdentity GetInfoComplex(ProjectIdentity request)
{
Console.WriteLine($"Incoming parameter value: {JsonSerializer.Serialize(request)}");
return request;
}
This is the change on Javascript side;
OnButtonClick()
{
$.ajax({
type: 'GET',
url: "@Url.Action("GetInfoComplex", "Home")",
dataType: 'json',
contentType: 'application/json',
data: {"Id":"1", "ModificationId": "100"},
success: function (result) {
alert('Data submitted.');
console.log(result);
},
failure: function (result) {
alert("Something went wrong. Plese contact System Administrator.");
console.log(result);
}
});
}
Put a breakpoint on “return request;” and run the app. Here is the output;
Third test case – Binding to nested Complex Type
Let’s add a nested class inside parent class and run the same method;
//here is the problem. GET request will ignore nested object mapping
[HttpGet]
public Project GetInfo(Project request)
{
Console.WriteLine($"Incoming parameter value: {JsonSerializer.Serialize(request)}");
return request;
}
So how we can fix this problem in GET request? Auto mapping will not work and in this case we need to be implicit to map the properties. Here is how;
//this is how to solve for GET request
[HttpGet]
public Project GetInfoFixed(
[FromQuery(Name = "Id")] int ProjectId,
[FromQuery(Name = "ProjectIdentity[Id]")] int ProjectIdentityId,
[FromQuery(Name = "ProjectIdentity[ModificationId]")] int? ProjectModificationId)
{
var response = new Project() { Id = ProjectId, ProjectIdentity = new ProjectIdentity() { Id = ProjectIdentityId, ModificationId = ProjectModificationId.Value } };
Console.WriteLine($"Incoming parameter value: {JsonSerializer.Serialize(response)}");
return response;
}
We are able to create full object graph this time.
Conclusion
As you have seen, that the ASP.NET MVC framework automatically converts request values into a primitive or complex type object. Model binding is a two-step process. First, it collects values from the incoming HTTP request, and second, it populates primitive type or a complex type with these values.
Value providers are responsible for collecting values from requests, and Model Binders are responsible for populating values.
By default, the HTTP methods GET, HEAD, OPTIONS, and DELETE do not bind data implicitly from the request body. To bind data explicitly from the request body, marked as JSON, for these methods, we can use the [FromBody] attribute. Also, we can use the [FromQuery] attribute.
Use POST for destructive actions such as creation (I’m aware of the irony), editing, and deletion, because you can’t hit a POST action in the address bar of your browser. Use GET when it’s safe to allow a person to call an action. So a URL like:
http://myblog.org/admin/posts/delete/357
Should bring you to a confirmation page, rather than simply deleting the item. It’s far easier to avoid accidents this way.
2 column layouts are rather popular on the web, and there are 1,001 ways to make them work. The approach you choose really depends on the type of content you have, and how you want images and backgrounds to work. What I’ll show is the Razor _Layout and CSS to achieve the following look:
The Razor _Layout file can rely on partial views to handle each of the primary sections: top, navigation, sidebar, and footer. RenderBody will produce the primary content area.
A quick note on Html.Partial. If any sections, like the sidebar and navigation sections, require some logic or model information to build their piece of the UI, then use Html.Action instead of Html.Partial. Html.Action allows you to setup a little sub-request inside the current request and allow a controller action to build a model and select a view.
The CSS coming up assumes each partial view will render inside an element with an id matching it’s purpose (so the _top view renders a div with an id of top).
The trick is to use absolute positioning on the sidebar content, which is possible because we know the exact amount of space taken by the 2 sections at the top of the page, and we know the exact width of the content area (it is set explicitly in the CSS). You’ll probably want to give the body more space than the 300px given in the sample above (which was constrained so the screenshot would fit on this page).
