Continuing module resolution from request scope (#62)

[poke]

This continues the work started by @khellang in #62.

In order to allow for better route lookup, this changes the route list into a dictionary in the module (as already mentioned before in chat). That way, you can now look up a route handler by verb and path instead of having to iterate over the list for a match. In addition, this also has the side effect, that you cannot register multiple handlers for identical routes anymore (maybe this needs some better error handling in the module methods though).

The next step was to avoid creating all those handlers when a route is being activated. The solution is actually pretty simple if you think about what was going on before: All that was happening was that the originally registered route handler was wrapped twice, once with the before and after handler from the module, and then again with that final thing. But we don’t actually need to wrap anything here; instead, we can just combine all those handlers into a single one that does everything—so we basically inline all those wrapping. The result is a single handler that is being constructed at startup time, so we are not allocating any handler when the route is later being executed. We just call the correct things in the correct order.

Finally, I refactored that a bit since I was hitting a naming issue myself where I used both the requestScopedModule and the original module within the handler. To avoid this from happening, I extracted this out in its own method so that you have a clear interface (the method signature) about what will be captured within the created lambda expression.

[khellang]

Just an FYI; the RFC says methods are case sensitive

The method token is case-sensitive because it might be used as a gateway to object-based systems with case-sensitive method names.

But I don't think many implementations enforce this, including ASP.NET Core.

[jchannon]

Sales Pitch, Botwin is a RFC7231 enforcer 😄