appBuilder.Map("/something/something", doit =>
{
doit.Use<Pipepart1>();
doit.Use<Pipepart2>();
});
See that doit.Use<Pipepart2>()? Such construct implies that Pipepart2 should be compiled and loaded right now. This is simply not scalable. What I really want is Pipepart2 being loaded on demand only when the corresponding request is encountered.
Hmm. You seem to be talking about acouple of separate things - lazy instantiation of objects, lazy loading of modules/assemblies into the AppDomain, and early termination of OWIN Middleware modules.
You attach the middleware to the appBuilder via Map (or other methods) during application startup, so it will simply incur the assembly penalty at startup. An assembly is loaded the first time it is referenced in executing code in an AppDomain. This is fairly unavoidable in the .NET world, though I agree that it would be preferable if it were otherwise.
Secondly, that use thing is in fact executed during the map - it does all the configuration and setup that it needs to do on startup, and is ready to process requests that are handed to it. Internally it actually gets set up on an entirely new AppBuilder that the main one delegates to I believe, so it only gets invoked on a correct path match, not on every request - only the matching logic is invoked if the request makes it to that point in the pipeline.
The early termination was addressed in my previous post, of course.
Yes, assembly loading is exactly what I'm talking about.
>An assembly is loaded the first time it is referenced in executing code in an AppDomain. This is fairly unavoidable in the .NET world
Premature assembly loading was easily avoidable with Web.config where you specified the request filter and assembly qualified type name of a handler. Hope it will be covered in ASP.NET Core / OWIN someday.
Yes, you are right about the map: it allows you to select who handles what. Still Web.config stays a much better contender in that deep matter: it allows to attach modules without changing code. A common scenario like adding a custom auth module to existing web application is a breeze with Web.config.
Code-based map looks a bit clunky after experiencing the gifts of Web.config flexibility and efficiency.
The exact problem with Web.config modules is that they are never handled in your code, only in the config. It also is very IIS-specific, precluding it from working easily with other web servers cross-platform. With OWIN, by starting with code, there is nothing stopping you or someone else from making a config-file-driven middleware loader to accomplish the functionality you're looking for. i.e. app.LoadMiddlewareFromConfig("middleware.json")
The only thing that precludes Web.config from working cross-platform is the absence of reliable implementation of a cross-platform web server. For example, I don't even consider Nginx reliable on Windows; some nasty effects are in place. The best home for Nginx is Linux. The best home for IIS is Windows. Cross-platform sounds sweet in theory but in reality it goes down hill pretty fast with subtle defects.
appBuilder.Map("/something/something", doit => { doit.Use<Pipepart1>(); doit.Use<Pipepart2>(); });
See that doit.Use<Pipepart2>()? Such construct implies that Pipepart2 should be compiled and loaded right now. This is simply not scalable. What I really want is Pipepart2 being loaded on demand only when the corresponding request is encountered.