Asp.NetFramework Flashcards
Explain ASP.NET Core middleware
The middleware pipeline was integrated as a standard part of the new ASP.NET Core framework.
Each middleware is a piece of code which handles requests and responses. E.g. it can add stuff to HttpContext. It can redirect somewhere. etc. etc.
Middleware is configured in the Startup class.
In the Startup class there is a Configure method which has an IApplicationBuilder which contains methods to configure the middleware pipeline (i.e. the Use, Run, Map, MapWhen methods). Middleware can be added through anonymous functions like this:
app.Use(async (context, next) => {
// do stuff
// next.invoke();
});
So app.Use in that case is accepting a function/delegate which
i) takes as parameters the httpContext and another function, which returns a Task
ii) itself returns a Task.
The above function/delegate is a request delegate.
You can also create a class that contains an Invoke/InvokeAsync method to be called to do the work. It should contain a reference to the next middleware as a RequestDelegate. A RequestDelegate is a: Func, Task>, or in other words a Func, or in other words a delegate which takes a dictionary and returns a task.
Adding extension methods to IAppBuilder enables you to then call them like app.UseMyMiddleware() etc.
What is OWIN? What is Katana?
OWIN is a specification describing an abstraction between web servers and application components. It enables integration between any web server and application which implements the specification. One of its goals was to decouple ASP.NET applications from the IIS server - historically the only web server ASP.NET apps could run on due to dependencies. It facilitates a pluggable architecture and development of small application components known as ‘middlewares’.
Katana is an implementation of the OWIN specification, developed by Microsoft. It can be used within ASP.NET applications.
What is OWIN middleware and .NET core middleware?
OWIN’s middleware pipeline is a series of components that can inspect, modify, etc. the http request/response and thus add functionality to application. It works by plugging in middleware components that are called one after the other. Each middleware component added to the pipeline should return an AppFunc delegate to be called so it can do its work. This AppFunc delegate is a Func, Task>. It takes the context dictionary through which it can do work on the http request/response, and returns a Task.
Besides returning an AppFunc delegate, the middleware should accept another AppFunc delegate as a parameter. This is the next AppFunc that should be called after this ones work is finished.
Katana provides an AppBuilder class which contains methods to configure the pipeline.
The middleware pipeline was integrated as a standard part of the new ASP.NET Core framework. In the Startup class there is a Configure method which has an IApplicationBuilder which contains methods to configure the middleware pipeline (i.e. the Use, Run, Map, MapWhen methods). Middleware can be added through anonymous functions like this:
app.Use(async (context, next) => {
// do stuff
// next.invoke();
})
You can also create a class that contains an Invoke/InvokeAsync method to be called to do the work. It should contain a reference to the next middleware as a RequestDelegate. A RequestDelegate is a: Func, Task>, or in other words a Func, or in other words a delegate which takes a dictionary and returns a task.
What is commonly known as AppFunc in OWIN middleware?
The AppFunc is the OWIN application delegate function. Interactions between the web server and the application happen through calls to this delegate. It has the following signature:
Func, Task>
So it takes the environment dictionary (which contains info on the http request/response etc.), and should return a Task when processing is complete.
ASP.NET Core middleware IApplicationBuilder - what is the difference between the Use and the Run methods?
The Run method does not call the next middleware in the pipeline; So it does not accept the next middleware as a parameter.
How does endpoint routing middleware and endpoint middleware work?
Endpoint routing middleware - decides what route use for a request. On startup all endpoints (controller actions) are registered. Upon a request the endpoint routing middleware selects which one to use.
The endpoint middleware is responsible for actually executing the endpoint action.
Extra info: The endpoints themselves are wrappers/classes that contain a request delegate, i.e. a function which actually executes the action.
What is an ASP.NET filter? What is the difference between a filter and middleware?
Filter - code that can be configured to run at a certain stage of the MVC request/response pipeline. They run after middleware, after an action has been selected to execute.
Middleware is similar, but runs before/after MVC context. So if you need anything that’s MVC specific you need a filter. E.g. model binding won’t have run yet within the middleware pipeline.
Why ever use middleware?
- Runs on every request
- If you have a cross-cutting concern that doesn’t depend on MVC, makes sense to use middleware. Shouldn’t make that code dependent on MVC.
What are:
Authorisation filters?
Resource filters?
Middleware filters?
Auth filter runs first, controls access to action methods (checks auth stuff).
Resource filters run right after auth filter, and are the last thing to run before exiting MVC context. Useful for e.g. getting a cached resource.
What are Type filters and Service filters?
todo
What are action filters, result filters and exception filters?
Action filters run immediately before and after an action is executed.
Result filters run before and after an ActionResult is executed.
(Actions (i.e. controller methods) return ActionResults that are then executed by the framework).
Exception filters act on unhandled exceptions that occur before the response body has been written to.
How does ASP.NET Core model binding work? What are model binder providers, value providers, input formatters?
Essentially - HTTP request comes in with data, model binder provider is used to obtain a model binder for it, this uses a value provider to extract data from the request and then creates the model/type that the controller expects. Model binding is essentially translating incoming request data into the C# type that the controller method expects in it’s parameters.
Data can come from form fields, the request body, the route, query string parameters or uploaded files.
Model validation is also performed, applying any validation rules defined on the type and adding results to ModelState.
