Supplementary Notes on "Linux. NET learning notes (8,
One or two days ago, "Linux. NET learning note (8)" was released. This article mainly describes how the OWIN framework and OwinHost communicate with each other to form a complete system based on the OWIN protocol. In this article, we also learn how to directly operate the OWIN dictionary and use data from OwinHost directly.
However, after the article was published, a friend reminded me that the article had some details. After I carefully measured it, I found that something really happened and it was not an insignificant small problem, I was going to deprecate the article and re-launch it after it was revised. The netizen "Wang Ye" reminded me that I could write a supplement for the article. This is quite a feeling of writing a manuscript. In consideration, I accepted the advice of Wang Ye. "Linux. NET learning notes" is a kind of personal learning record, which is also a kind of manuscript. So we have a supplement to this article.
Linux. NET learning note (8) mainly makes the following mistakes:
1. mistaken "Microsoft. OWIN" as "OWIN" to extend the concept of "OWIN.
2. "Middleware" is not required by OWIN.
3. the adapter is not used in this way.
1. "Microsoft. OWIN" is not equal to "OWIN"
In Linux. NET learning note (8), although there is no point in this article that "Microsoft. OWIN is a saying of "OWIN", but in the Writing Method of the article, it is very easy to lead readers astray, making readers mistakenly think that "OWIN" is actually "Microsoft. OWIN ". What is "OWIN", "OWIN" is a protocol, a dictionary, which contains Environment, and "OWIN. dll" is actually just an interface, with no more. All the things derived from "OWIN" are no longer the OWIN itself.
Therefore. NET learning note (8) should change all "OWIN" to "Microsoft. OWIN, indicating that this is for "Microsoft. "OWIN.
2. "Middleware" is actually something of "Microsoft. OWIN ".
Here, I need a picture to explain why I have misjudgment in the existing OWIN framework and why I have written:
Although the OWIN protocol does not belong to any party, the earliest implementation of the OWIN protocol is Microsoft's "Microsoft. therefore, many of the current OWIN frameworks are based on Microsoft. to implement. Components such as "Startup", "Configuration", and "Middleware" are the knowledge points proposed by "Microsoft. OWIN". Therefore, these OWIN frameworks naturally come into being.
Therefore, the "turning our key" mentioned in this article is actually the key to turning "Microsoft. OWIN" instead of the entire "OWIN" door.
3. Real usage of the adapter
The previous section has made it very clear that the existing OWIN frameworks are all for "Microsoft. the OWIN framework is a seamless connection between these OWIN frameworks and Katana. There is no need to use this type of adapter, while Jexus is different, adapter is based on. the OWIN framework implemented by OWIN can be implemented in Jexus. owinHost uses the generated components (thanks to the reminder from the original author of Jexus). The concept diagram provided by yun.com is shown below:
Even if you do not understand the OWIN itself, it does not have much impact on daily development (unless you directly operate the OWIN dictionary). The framework is still used, and the project is still developed. However, I personally have high requirements on Knowledge accuracy and need to be meticulous. If more friends find other errors, you are welcome to point them out. Thank you.