OWIN et Katana - Qu'est-ce que les middlewares sont vraiment?

Question

Lorsque vous travaillez avec Katana Project, nous traitons beaucoup avec les middlewares. Comme mentionné précédemment sur le site Web ASP.NET disent-ils

, lorsque le serveur accepte une demande d'un client , il est responsable de passer à travers un pipeline de OWIN composants, qui sont spécifiés par le code de démarrage du développeur . Ces composants de pipeline sont connus sous le nom de middleware.

C'est bien, mais je ne comprends pas. Au début, je pensais que les middlewares étaient les composants ASP.NET comme WebAPI, SignalR et tout cela. Cependant, en étudiant l'authentification, j'ai vu le Middleware d'authentification de cookie. Celui-ci n'est pas un framework complet comme WebAPI, donc il ne correspond pas à mon idée initiale de middleware.

Alors, quels sont les middlewares Katana? Ce sont juste des morceaux de code qui peuvent être intégrés dans le pipeline d'exécution et qui fonctionnent sur le dictionnaire d'environnement? Et donc, ils peuvent être des composants simples comme un middleware d'authentification ou des interfaces pour communiquer avec des frameworks entiers comme WebAPI?

Answer 1

Si vous êtes familier avec le cycle de vie des applications ASP.NET et son pipeline de traitement,

http://www.iis.net/learn/application-frameworks/building-and-running-aspnet-applications/how-to-take-advantage-of-the-iis-integrated-pipeline

Vous avez probablement quelques idées de base sur ce qui est le middleware. Le pipeline lui-même (principalement les types dans System.Web) est un middleware, qui relie vos applications ASP.NET (WebForms, MVC) à l'hôte sous-jacent (serveurs Web, tels que IIS, IIS Express, Cassini, selfhost et ainsi de suite).

Cependant, le classique System.Web est fortement couplé, puis vient OWIN et Katana. Si vous plongez dans la base de code de Katana, vous vous verrez comme un pipeline. Il est beaucoup plus flexible et hautement personnalisable, ce qui veut dire que le middleware est maintenant plus concis que jamais. ASP.NET vNext se débarrasse complètement de System.Web, de sorte que vous pouvez voir comment Katana joue un rôle important dans les mois à venir.

Answer 2

Les middlewares sont aussi simples que de penser à la composition d'une fonction mathématique. Le OWIN (nearly) spec'd signature est Func<AppFunc, AppFunc>, où using AppFunc = Func<IDictionary<string, object>, Task>.

Si vous pensez en termes de composition de fonction, le but devient clair:

val f : int -> int 
let f x = x*x 

val g : int -> int 
let g x = x+x 

Vous pouvez appeler ces manuellement:

val result1 : int -> int 
let result1 x = g(f(x)) 

Ou vous pouvez composer les fonctions pour créer une nouvelle fonction:

val result1 : int -> int 
let newFunc = g • f 
// or in F# 
let newFunc = g << f 

Retour à OWIN, encore en utilisant la notation F # pour rester simple:

type AppFunc = IDictionary<string, obj> -> Task 
val app : AppFunc 
val middleware : AppFunc -> AppFunc 

Application mon app-middleware crée une nouvelle app':

let app' : AppFunc = middleware app 

Un exemple concret est celui d'un middleware de l'exploitation forestière.Suite à la composition, vous constaterez que la demande coule comme ceci:

request -> loggingMiddleware -> app -> loggingMiddleware -> response 

vous donnant l'occasion de se connecter à la fois la requête entrante et sortante réponse. C'est effectivement la même chose que HttpMessageHandler de l'API Web.

Katana rend ce plus simple pour les développeurs C# par IAppBuilder et l'extension .Use, ainsi que chaque bibliothèque middleware exposant une méthode d'extension raccourci, comme .UseWebApi ou .UseSignalR. De plus, Katana utilise des middlewares pour monter des frameworks afin de pouvoir utiliser un mécanisme d'accès direct, basé sur un code d'état de réponse 404, pour essayer de gérer la requête avec un autre framework. Vous pouvez gérer cela différemment par mounting frameworks at different paths, mais ce mécanisme fonctionne bien si vous voulez gérer différentes parties de votre application sous un chemin unifié en utilisant des frameworks différents.