Exploring ASP.NET core
ASP.NET Core is a cross-platform framework for building modern applications. ASP.NET Core apps can run on .NET Core or on the full .NET Framework.
ASP.NET Core was designed to decouple web applications from the underlying HTTP server.
Components of ASP.NET core
.NET Core is a subset of .NET Framework 4.6 which is mainly optimized for multi-platform and cloud deployments
Kestrel web server is a built-in cross platform web server (Microsoft.AspNetCore.Server.Kestrel)
Benchmarking
Latest benchmarks are available on github.
Major Features
Startup:
ASP.NET Core provides complete control of how individual requests are handled by your application. The Startup class is the entry point to the application, setting up configuration and wiring up services the application will use. Developers can configure a request pipeline in the Startup class that is used to handle all requests made to the application.
Services:
A service is a component that is intended for common consumption in an application. Services are made available through dependency injection. ASP.NET Core includes a simple built-in Inversion of Control (IoC) container that supports constructor injection by default, but can be easily replaced with your IoC container of choice. This ensures loose coupling between components, dependency injection makes services available throughout your app.
Middleware:
Framework allows lightweight and modular HTTP request pipeline with middleware. HTTP handlers and HTTP modules are replaced with middleware. Which means, Global.asax and web.config are gone.
Pipeline branching lets you send requests to specific middleware based on URL, request headers, query strings etc.,
How is middleware different from HTTP modules?
HttpModules act as request filters in classic ASP.NET versions. They are reusable units of code that can be plugged into the request pipeline, and tasked with responding to events defined in the HttpApplication class as they are fired.
Middleware can be thought of as both HTTP modules and handlers that we’ve had in classic ASP.NET. Some middleware would implement various intermediate tasks when processing requests such as authentication, session state retrieval and persistence, logging, etc., Some will be ultimate request handlers that would produce responses.
Here‘s a quick summary of differences in behaviour:
- Invoked in principle for every request
- Able to short-circuit a request, by not passing the request to the next middleware
- Able to create their own HTTP response
- Order of middleware is based on the order in which they are inserted into the request pipeline, while order of modules is mainly based on application life cycle events
- Order of middleware for responses is the reverse from that for requests, while order of modules is the same for requests and responses
Configuration:
ASP.NET Core uses a new configuration model for handling simple name-value pairs. The new configuration model is not based on System.Configuration or web.config; rather, it pulls from an ordered set of configuration providers. The built-in configuration providers support a variety of file formats (XML, JSON, INI) and environment variables to enable environment-based configuration. We can also write our own custom configuration providers.
Deployment Environments:
ASP.NET Core references a particular environment variable, “ASPNETCORE_ENVIRONMENT” to describe the environment the application is currently running in. This variable can be set to any value you like, but three values are used by convention: Development, Staging and Production. You will find these values used in the samples and templates provided with ASP.NET Core.
