Explore topic-wise InterviewSolutions in Current Affairs.

Most applications require storing and retrieving data. Usually, we store this data in a database. Working with databases can often be rather complicated. You have to manage database connections, convert data from your application to a format the database can understand, and handle many other subtle issues.

The .NET ecosystem has libraries you can use for this, such as ADO.NET. However, it can still be complicated to manually build SQL queries and convert the data from the database into C# classes back and forth.

EF, which stands for Entity Framework, is a library that PROVIDES an object-oriented way to access a database. It ACTS as an object-relational mapper, communicates with the database, and maps database responses to .NET classes and objects.

Entity Framework (EF) Core is a lightweight, open-source, and cross-platform version of the Entity Framework.

Here are the essential differences between the two:

Cross-platform:

• We can use EF Core in cross-platform apps that target .NET Core.
• EF 6.x targets .NET Framework, so you’re limited to Windows.

Performance:

• EF Core is fast and lightweight. It significantly outperforms EF 6.x.

FEATURES:

• EF Core has some features that EF 6.x doesn’t have (batching statements, client-side key GENERATION, in-memory database for testing)
• EF 6.x is much more feature-rich than EF Core. EF Core is missing some headline features at the time of writing, such as lazy-loading and full server-side Group By. However, it is under active development, so those features will no doubt appear soon.

Not all web applications return an HTML view as a response to an HTTP request. Sometimes, a client only wants some data from your application, and it wants to handle how that data will be formatted.

For EXAMPLE, let's say your application supports both web and mobile interfaces. Instead of WRITING two separate projects which return HTML and mobile views, you can write a single application that only RETURNS the specific data that the clients need. Once the clients receive this data, they format it accordingly. The web client renders the HTML using view templates and JavaScript, and the mobile clients generate the appropriate mobile view for its specific platform.

An application might also need to communicate with another application to fetch the data that it needs. For example, when you go to Amazon.com, it communicates with hundreds of other services and applications to retrieve data and renders the final HTML page you see.

Such back-end applications, which provide data, are commonly known as RESTful web services. REST protocol uses verbs LIKE GET, POST, PUT, DELETE to communicate between multiple applications. The client and server can be written in different languages and technologies and STILL work together without knowing about each other, as long as each side knows the format of the data that is getting sent.

ASP.NET Core supports creating RESTful services, also known as web APIs, using C#. A Web API consists of one or more controllers that derive from ControllerBase class.

[PostController]
[Route("[controller]")]
public class PostController : ControllerBase

An MVC controller derives from the Controller class. However, a Web API controller should derive from the ControllerBase class. The reason is that Controller derives from ControllerBase and provides additional support for views, which you don’t need for web API requests.

That said, you can use a controller for both rendering views and data. That is, it can act as both an MVC controller and a Web API controller. In this case, you can derive the controller from the Controller class.

Attribute ROUTING is an alternative routing strategy for conventional routing. It is often used to create REST API endpoints for web services. It uses a set of attributes to map action methods directly to route templates.

Attribute routing directly defines the routes on action methods. We can also use these attributes on the controllers. It enables us to get fine-grained control over what routes map to which actions. With attribute routing, the controller and action names play no part in determining the action method.

For example, we use attributes Blog and Home to map an incoming URL such as myapp.com/blog/post/3 to the Show method on the PostsController.

In the above example, the attribute [Route(“blog”)] is placed on the controller, whereas the route [HttpGet(“post/{id:int}”)] is placed on the action method. A controller route APPLIES to all actions in that controller. For example, the second [“edit/{id:int}”] route matches the url myapp.com/blog/edit/3.

In ADDITION to the above route templates, ASP.NET Core provides the FOLLOWING HTTP verb templates.

• [HttpGet]
• [HttpPost]
• [HttpPut]
• [HttpDelete]
• [HttpHead]
• [HttpPatch]

As the name suggests, conventional routing USES predefined conventions to match the incoming HTTP request to a controller’s ACTION method. It handles the most general cases that a typical web application needs, but you can modify it to SUIT your specific needs.

For example, the CONFIGURE() method in the Startup.cs class contains the following code that sets up the conventional routing.

This code creates a single route named ‘default’. The route template pattern ‘{controller=Home}/{action=Index}/{id?}’ is used to match an incoming URL such as /Posts/Archived/5 to the Archived(int id) action method on the PostsController, passing 5 for the id parameter. By default, the router uses the Index method on the HomeController. 

Routing is the process of mapping an incoming HTTP REQUEST to a specific method in the application code. A router maps the incoming requests to the route handler. It takes in a URL as an input and deconstructs it to determine the controller and ACTION method to route the request.

A simple routing pattern, for example, might determine that the /posts/show URL maps to the Show action method on the PostsController.

There are two ways to define routes in an ASP.NET Core MVC application. 

• Conventional Routing
• Attribute-Based Routing.

We can use both Conventional Routing and Attribute Routing in an application.

In general, middleware is plumbing software that facilitates communication flow between two components. In a web application framework, middleware provides common services and capabilities to the application outside of the default framework.

In ASP.NET Core, middleware refers to the C# classes that manipulate an HTTP request when it comes in or an HTTP response when it’s on its way out. For EXAMPLE,

Generate an HTTP response for an INCOMING HTTP request
Intercept and make changes to an incoming HTTP request and pass it on to the next piece of middleware.
Intercept and make changes to an OUTGOING HTTP response, and pass it on to the next piece of middleware.

One of the most common use cases for middleware is to deal with concerns that affect your entire application. These aspects of your application need to occur with every request, regardless of the specific path in the request or the resource REQUESTED. These include things like logging, security, authentication, authorization, etc.

For example, logging middleware logs when a request comes in and passes it to another piece of middleware. Some other common middleware USES include database middleware, error handling middleware, and authentication/authorization middleware.

In each of these examples, the middleware receives a request, modifies it, and then passes it to the next middleware piece in the pipeline. Subsequent middleware uses the details added by the earlier middleware to handle the request in some way. The following diagram illustrates this.

A cookie is a small amount of data that is persisted across REQUESTS and even SESSIONS. COOKIES store information about the user. The browser STORES the cookies on the user’s computer. Most browsers store the cookies as key-value pairs.

Write a cookie in ASP.NET CORE:

Response.Cookies.Append(key, value);

Delete a cookie in ASP.NET Core

Response.Cookies.Delete(somekey);

ASP.NET Core injects instances of dependency CLASSES by using the built-in IoC (Inversion-of-Control) container. This container is represented by the IServiceProvider interface that supports constructor injection.

The types (classes) managed by the container are called services. To let the IoC container automatically inject our services, we first need to register them with the IoC container in the Startup class.

ASP.NET Core supports two types of services, namely FRAMEWORK and application services. Framework services are a PART of ASP.NET Core framework such as ILoggerFactory, IApplicationBuilder, IHostingEnvironment, etc. In contrast, a developer creates the application services (custom types or classes) SPECIFICALLY for the application.

HTTPCONTEXT encapsulates all HTTP-specific information about an individual HTTP request. You can access this object in controllers by USING the ControllerBase.HttpContext PROPERTY:

ASP.NET Core has MANY DIFFERENT types of IActionResult:

• ViewResult—Generates an HTML view.
• RedirectResult—Sends a 302 HTTP redirect response to send a user to a SPECIFIED URL automatically.
• RedirectToRouteResult—Sends a 302 HTTP redirect response to automatically send a user to another page, where the URL is defined using routing.
• FileResult—Returns a file as the response.
• ContentResult—Returns a provided string as the response.
• StatusCodeResult—Sends a raw HTTP status code as the response, optionally with associated response BODY content.
• NotFoundResult—Sends a raw 404 HTTP status code as the response.

An ACTION method is a method in a controller class with the following restrictions:

1. It must be public. Private or protected methods are not ALLOWED. 
2. It cannot be overloaded.
3. It cannot be a static method.

An action method executes an action in response to an HTTP request.

For example, here is an example of an Index() action method on the PostController. It takes an ID as an input and returns an IActionResult, which can be implemented by any result classes (SEE the following question).

Controllers and views need to work with data that comes from HTTP requests. For example, routes may provide a key that identifies a record, and posted form FIELDS may provide model properties. The process of converting these string values to .NET objects could be complicated and something that you have to do with each request. Model binding automates and simplifies this process. 

The model binding system fetches the data from multiple sources such as form fields, route data, and query strings. It also provides the data to controllers and views in method parameters and properties, converting plain string data to .NET objects and types in the process.

Example:
Let’s say you have the following action method on the PostsController class:

And the app receives a request with this URL:

After the routing selects the action method, model binding EXECUTES the following steps.

• Locate the first parameter of GetByID, an integer named id, look through the available sources in the HTTP request and find id = "5" in route data.
• Convert the string "5" into an integer 5.
• Find the next parameter of GetByID, a boolean named archivedOnly.
• Look through the sources and find "ArchivedOnly=true" in the query string. It ignores the case when matching the parameters to the strings.
• Convert the string "true" into boolean true.

Some other examples of attributes include:
1. [FromQuery] - Gets values from the query string.
2. [FromRoute] - Gets values from route data.
3. [FromForm] - Gets values from posted form fields.
4. [FromBody] - Gets values from the request body.
5. [FromHeader] - Gets values from HTTP HEADERS.