ASP.Net 5 vNext Middleware for modular websites

Question

I'm at very beginning of learning new version of ASP.Net 5, and at this point I'm already impressed about all new features they introduced. The most awaited by me is built-in DI system.

Currently I'm working in a company with about 15 sites, and all of them are almost similar by structure but each one have few individual things.

So, I plan to do some kind of mini CMS for our sites, something like modularity in PRISM, using new features of vNext.

Now, I'm trying to make few basic middlewares (like store, services, blog, chat or whatever), but I'm stucked here.

Question 1: Can middleware be used to act as independent modules for a site with his own routes, controllers, admin panel extensions, etc.?

if - yes, then...

Question 2: How can I handle routing requests from Invoke method of middleware?

I read all the docs available for now at http://docs.asp.net , but middleware example used there is pretty simple, isn't enought to start writing middleware used in real-world app.

Edit 1: I'm wondering, if middleware can act like IModule in PRISM?

In PRISM, I register types and views inside of IModule, it's like a glue for all module's components. For example: I have PRISM based application with few modules: Accountant, Products, Documents, Mailer and so on. Each module have its own Models, ViewModels, Views, etc, and almost each module can be decoupled or modified without affecting another one. Each doing his job without really knowing about other modules.

I'm trying to understand if I can do something like that for web using vNext. For example: Blog module doesn't need to know something about Store.

So, can I do separate Class Libraries for each needed module, and use middleware like I use IModule in PRISM?

PS Any example will be greatly appreciated. Thanks in advance.

Answer 1

Middlewares in ASP.NET replace http modules. You can't build

store, services, blog, chat or whatever

using http modules (or middlewares). They work in a context of a http request.

The modules you are talking about are higher level concepts. It's a different level of abstraction.

Answering your questions:

1. They are not the type of modules you're thinking of. No
2. MVC middlewares already handle routing. I don't think you need to reimplement this. Just use it.