Home > News content

ASP.NET Core: simple power

via:博客园     time:2018/5/30 16:51:01     readed:862

English Original:ASP.NET Core - The Power of Simplicity

Key points

  • When building Web applications, OWIN provides a good Web server abstraction for developers.
  • ASP.NET Core is divorced from the standard OWIN implementation, which is a simplification for developers.
  • Simplifying complex things by abstraction does not weaken it, but makes it simpler and easier to use.
  • By using middleware instead of advanced frameworks, developers can build concise and powerful applications.
  • Even without the use of ASP.NET Core, you can use the Katana in the old solution to get the relevant functions.

With the release of.NET Core 2, the first common, modular, cross platform, and open source platform, which was originally published in 2016, has the latest major version. .Net Core contains a lot of API available in the current version of.NET Framework. Its original purpose is to support the next generation of ASP.NET solutions, but now it has become the basis for other scenarios, including the Internet of things, cloud computing, and next generation mobile solutions. In this series, we'll look at some of the advantages of.NET Core and how it benefits traditional.NET developers and all the technicians who need to provide a powerful, high-performance, and economic solution for the market.

This is.RSSReceive update notifications.

When Microsoft decided to restructure their Web development platform ASP.NET, they thought it might not be a good idea to bind it to IIS. The original ASP.NET is built on the specific technology of IIS, which not only leads to the binding of ASP.NET to Windows, but also can not be self managed. These constraints make it very difficult to cut into the cloud centric world. Microsoft decided to fully open the Open Web Interface for.NET (or OWIN), and comprehensively abstract the Web server. Users of frameworks and frameworks can completely ignore which servers are responsible for processing which HTTP requests, and they can focus on building the required functions.

However, OWIN is not a new concept. OWIN specification has been in existence for several years, and Microsoft has long allowed developers to use OWIN in IIS, through an open source project called Katana. In fact, Microsoft not only allows developers to use OWIN through Katana, but in recent years, OWIN has become the foundation of all ASP.NET authentication functions.

So, what exactly is OWIN? To be honest, it's a very simple thing! It is this simplicity that makes it so great. It is an interface that abstracts the Web server by using predefined agents and a general dictionary consisting of strings and objects. Therefore, instead of using event driven architecture, it defines a pipeline called middleware.

The middleware is actually a piece of code that interacts with requests from clients .

The middleware then consists of a pipeline, and the incoming message passes from one middleware to another in the order that middleware is added to the pipeline, until one of the middleware knows how to generate the response message. The response message is then sent back to the pipeline for inspection, and the middleware may modify it before sending it to the client. The principle is very simple, but still very flexible and powerful.

This process is called the request pipeline, and the message flows through the pipeline, and the middleware interacts with it when it flows. However, pipes need some form of pipe object to transfer messages between middleware. In OWIN, middleware is actually more like a linked list. Incoming requests are passed to the first Middleware in the list, and then processed to the next middleware. The request is passed from one middleware to another, until one of them generates a response message and sends the response message back to the list, allowing the previous middleware to check the response message. In fact, the process is a bit complicated because the response message should actually be sent to the client immediately after the generation, even before it is returned to the pipeline. This makes it more complicated to modify the response message, but for simplicity's sake, we ignore this part.

The OWIN specification defines incoming requests as dictionaries composed of strings and objects. The server receives the incoming HTTP request, splits the request information into the available block, and puts it into the dictionary, and then passes it to the first middleware for processing. It uses predefined keywords to add the request path, header information set, including the flow of the message body to the dictionary. The middleware uses these keywords to read the required information from the dictionary and complete the corresponding processing. In addition, the server adds an object that is used to generate response messages to the dictionary, such as ringing and responding to the header information set, and the middleware can generate the response by using the object in the dictionary and send it to the client. Most importantly, the server can actually add agents to the dictionary to provide additional functions to the middleware. For example, there is a OWIN specification extension that allows the server to provide a specialized way to send files to the client. The server is exposed to the middleware by providing a predefined proxy in the dictionary. Then, the middleware can query the dictionary to see whether the current server supports this function. If so, the invocation agent will send the file to the client.

The OWIN interface is very simple, but also powerful. It provides us with low-level access to HTTP requests and responses, and abstracts the cumbersome details of processing actual requests. However, it does not limit our ability to provide higher level abstraction by proxy. On the other hand, because it's too low-level, sometimes it is a bit troublesome to use it. I think that's why Microsoft decided to embrace OWIN in its own way.

Microsoft made some changes to the OWIN pipeline when it added it to ASP.NET Core. Or, they added a layer to make it easier to operate (at least that's what I see. Instead of just providing a generic dictionary for middleware, they added a type layer to make it easier to use. So instead of getting a dictionary, we get a HttpContext object so that we can interact with requests and responses in a simpler way. For example, we could use httpContext.Response.Body.Write.) Returns a message to the client, instead of using the dictionary

In the Katana project, the HttpContext wraps the dictionary so that we can access the data items in a typed way. In ASP.NET Core, on the other hand, it is a fully custom object. However, if we want to use OWIN-based middleware, we can use some available extensions to provide

So, do we really need to use such low-level API to build applications? Of course not! It's quite easy to build more advanced abstraction on this low-level API, which is exactly what Microsoft has done. In ASP.NET Core, ASP.NET MVC is a middleware implementation. It contains several services that are injected into the middleware using the.NET Core dependency injection function, but it itself is a middleware that is responsible for interacting with the client's requests. This is where the underlying API plays its power.

Because we can register as many middleware as we want in the request pipeline, we can add the framework and functionality we want to use. Want to use ASP.NET MVC to generate UIs? Don't worry, just add MVC middleware and support services. Want to use Nancy Fx in API? No problem, just add it to the request pipeline. Want to use Facebook authentication? No problem! Simply add the required middleware and services. Want to combine Twitter authentication with JWT tokens for use in your API? Add middleware. I'm sure you understand.

I did not write a complete article for the ASP.NET Core request pipeline, nor did I have any code to show how it works. So, we take authentication as an example. This is one of the most common ways to understand OWIN, and it's also a good example of displaying the powerful functionality of the interface, so it seems appropriate to use it here.

Adding authentication to the ASP.NET Core Web application means adding something to the application. First, we need to add the authentication service to the collection of services, and then tell it the different types of authentication we want to support.

Suppose we want to use Facebook authentication, and after users authenticate, we hope to use Cookie authentication to authorize them. The configuration looks like this:

Public void ConfigureServices (IServiceCollection services) {

.AddFacebook (

Once these services are available, you can add authentication middleware to the request pipeline like this:

public void Configure (IApplicationBuilder app, IHostingEnvironment env) {        // Middlewares that don

Finally, when we want to redirect users to Facebook for authentication, we only need to call:

await HttpContext.ChallengeAsync (   new AuthenticationProperties { RedirectUri = "/userinfo" },    FacebookDefaults.AuthenticationScheme);}

This call will use the defined authentication scheme to set up HttpContext and redirect the user to the correct login page. In this case, the Facebook authentication handler sets the returned state code to HTTP 302 and sets the location header field to the authentication address of the Facebook so that the client is redirected to the address. Once users authenticate through Facebook and are redirected to an application with identity tokens, the authentication middleware captures the callback and uses the Facebook service to verify the token. If everything is normal, it will require the Cookie authentication service to issue a Cookie to keep the client login. In fact, this means that the Cookie authentication service adds a header information to the response header Dictionary of the HttpContext and then adds it to the response message.

By using several extensions to register some services and a middleware, we have established a fairly complex authentication process, redirecting the user at the request for authentication, and processing the callback from the identity provider when the authentication occurs.

Note: in previous configuration, it will actually try to verify user identity with Cookie authentication instead of Facebook authentication. But only a small configuration change is needed to make Facebook the default authentication mechanism, but this is beyond the scope of this article.

I hope you agree with me that migrating to a OWIN-based pipeline is a good thing. It may be a very simple underlying interface, but if used properly, it can be powerful. It is not easy to create an easy interface that can accommodate both low-level and advanced usage without limiting the future. But I'm sure this interface can do it. Now, we need to make the most of it! As long as you're a little creative, there's nothing to limit you.

About the author

orgsrc=https://images2018.cnblogs.com/news/66372/201805/66372-20180530155812863-1295940098.jpg

Chris Klug is a software developer and architect in tretton37, Stockholm, Sweden. He spent a lot of his life solving problems by writing software. He liked the creativity of coding and the challenges he faced in the coding process. He also spent a lot of time making speeches at developers' conferences around the world, which obviously attracted Microsoft's attention and awarded him MVP awards. But when asked about his interests, he admits that he prefers to fly a kite on a beautiful beach or to continue to expand his tattoo on a computer.

With the release of.NET Core 2, the first common, modular, cross platform, and open source platform, which was originally published in 2016, has the latest major version. .Net Core contains a lot of API available in the current version of.NET Framework. Its original purpose is to support the next generation of ASP.NET solutions, but now it has become the basis for other scenarios, including the Internet of things, cloud computing, and next generation mobile solutions. In this series, we'll look at some of the advantages of.NET Core and how it benefits traditional.NET developers and all the technicians who need to provide a powerful, high-performance, and economic solution for the market.

China IT News APP

Download China IT News APP

Please rate this news

The average score will be displayed after you score.

Post comment

Do not see clearly? Click for a new code.

User comments

Related news