Skip to content

Home

Jump to bottom
Pete Restall edited this page Mar 23, 2018 · 11 revisions

Contents

  1. Asynchronous Method Signatures
  2. Injecting NancyContext into your Services
  3. Customising RouteRegistrar Semantics
  4. Release 2.3.0 Changelog
  5. Release 2.1.0 Changelog
  6. Release 2.0.0 Changelog

1. Asynchronous Method Signatures

The signatures of Service Methods that can be dispatched asynchronously are as follows:

    public async void VoidMethodDecoratedWithAsync(Request request);
    public async Task TaskMethodDecoratedWithAsync(Request request);
    public async Task<Response> TaskOfTMethodDecoratedWithAsync(Request request);

    public Task TaskMethodNotDecoratedWithAsync(Request request);
    public Task<Response> TaskOfTMethodNotDecoratedWithAsync(Request request);

Methods requiring Cancellation Tokens are also supported and these take the form:

    public async void VoidMethodDecoratedWithAsync(Request request, CancellationToken cancel);
    public async Task TaskMethodDecoratedWithAsync(Request request, CancellationToken cancel);
    public async Task<Response> TaskOfTMethodDecoratedWithAsync(Request request, CancellationToken cancel);

    public Task TaskMethodNotDecoratedWithAsync(Request request, CancellationToken cancel);
    public Task<Response> TaskOfTMethodNotDecoratedWithAsync(Request request, CancellationToken cancel);

Remember to return Task and Task<T> instances when they're hot, as discussed in the Nancy Async Wiki.

Like their synchronous Service Method counterparts, asynchronous Service Methods returning void and Task will return a default response back into Nancy's pipeline; see the RouteDispatchBuilder.WithDefaultResponse(...) method for customising this.

All other method signatures will be routed synchronously (if they're supported), unless you inject your own semantics into the RouteRegistrar object graph as discussed below.

2. Injecting NancyContext into your Services

Sometimes a NancyContext will be required by a Service that needs to get at Per-Request constructs which ordinarily would have been available to you if you were using regular NancyModule-based Routing. A common scenario might be when using other Nancy Plugins, such as Nancy.Linker.

A NancyContext can be injected into your Service's constructor like any other dependency that has been registered with Nancy's IoC Container. However, since Contexts are scoped Per-Request rather than at the Application level, the Bootstrapper implementation needs to look something like:

    public class Bootstrapper: DefaultNancyBootstrapper
    {
        protected override void ConfigureRequestContainer(
		    TinyIoCContainer container, NancyContext context)
        {
            base.ConfigureRequestContainer(container, context);
            container.Register((ctx, args) => context);
            container.Register((ctx, args) =>
			    RouteRegistrarFactory.CreateDefaultInstance(ctx.Resolve));
        }

        ...
    }

Note that wiring in the RouteRegistrar is not done in the ConfigureApplicationContainer() overload because its Service Factory now has to be scoped Per-Request. The NancyContext is effectively closed over as a Singleton for the duration of the Request until the IoC Child Container dies.

3. Customising RouteRegistrar Semantics

The RouteRegistrar class provides the Facade by which the Nancy.ServiceRouting library is hooked into Nancy. A default instance of the Facade can be created via RouteRegistrarFactory.

Assuming it's been injected into your NancyModule - although it doesn't have to be - it can be tweaked to provide custom behaviour:

    public class ApiModule: NancyModule
    {
        public ApiModule(RouteRegistrar registrar)
        {
            registrar
                .WithDispatchContext(ctx => ctx
                    .WithServiceFactory(SomeFactoryMethod)
                    .WithDefaultResponse(SomeResponseReturnedForVoidMethods))
                .RegisterServiceInto(this, typeof(AwesomeService));
        }
    }

There are more customisations available but they are all accessed via the RouteRegistrar.WithDispatchContext(...) method.

4. Release 2.3.0 Changelog

Added support for Custom Verbs, which are useful for adding meaning to RESTful service requests.

5. Release 2.1.0 Changelog

The significant change for Version 2.1.0 is support for Named Routes, which are useful for automatically building URIs from Routes without the need for magic path strings to be scattered throughout code and Views.

  • Added NamedRouteAttribute and associated boilerplate functionality to allow Named Routes
  • Updated all dependent NuGet packages to their latest versions

6. Release 2.0.0 Changelog

Version 2.0.0 adds support for asynchronous routing but introduces some breaking changes. Unless you have implemented your own IServiceMethodInvocation, IServiceRequestBinder or IServiceRouteResolver based on RouteAttributeServiceRouteResolver then you are unlikely to notice any differences from 1.0.0.

The notable breaking changes are:

Clone this wiki locally