In this course, we will look at how to get started developing applications with the Nancy framework. The Nancy framework (or NancyFX) is an open-source micro-framework built on .NET. NancyFX is lightweight, yet powerful. This course is designed to help you familiarize yourself with using NancyFX to build web applications with minimal ceremony.
Richard is a Senior Software Developer for Vertigo Software. He takes a holistic approach toward software development by exploring pan-technological and non-technological solutions to customer issues. Richard blogs about code and technology at http://elegantcode.com/author/rcirerol.
Introduction Hello, my name is Richard Cirerol, and today we're going to get started with an anti-framework, a Sinatra- inspired web framework for the. NET platform. You may be wondering if you even need another framework. You may be comfortable with WebForms or MVC, but let's take a look at those two projects before we get started. First of all ASP Net WebForms. WebForms uses a desktop development model for building web applications by including user and server controls as reusable components, page events, ViewState to simulate statefulness in a stateless environment, and the location of pages is based largely on one- to-one mapping of URI's files. ASP Net MVC uses the model view controller pattern, hence its namesake, and the framework separates logic from presentation. The framework also uses some convention-based structures, for example the folder structure, the location of the components in the folder structure help the framework locate specific objects such as areas, controllers and views. Routes are structured as well. The URI templates that make up the route values tell the framework how to respond to incoming URIs. A route table specifies the class and methods used for a particular URI. Routes are order dependent meaning the first route to match the URI template will be used. Nancy offers a slightly different model. There are very little requirements for file or folder structure, however similar to MVC there's some convention-based location of views and static files. Rather than being defined in a route table, routes are defined as part of the definition of the action. We'll see that here shortly. Any conventions imposed by the framework are free to be overwritten. Nancy's ideal for small to medium web applications and API projects.
Extending Nancy Modules Now that we've seen the basics of creating a module and routes, let's take a look at how we can hook into some extended features of the NancyModule, model binding and pipeline hooks. First, a recap from the last module. When a user agent such as a web browser sends a request message, the server receives the request, processes the request, and returns the response back to the user agent. In this module, we will dig deeper into the processing of the request. When processing a request, in order to return response, the engine must process a route. The engine first locates the route then invokes any BeforePipeline actions which may or may not return a response then invokes the route. The route has response and we may return it if we don't have any AfterPipeline actions. If we do have AfterPipeline actions, those were invoked and they may alter the response. If at any time during this pipeline, an exception is thrown, the error handler will kick in and return its own response. We'll first look at some built-in route functions, deserialization, and model binding and then we'll look at the before and after functions that allow us to hook into the Nancy request pipeline.
The Bootstrapper In this module, we will explore the Nancy Bootstrapper. What is the bootstrapper? Well, the bootstrapper is where the "magic" starts. You may think of the bootstrapper as the global. asax replacement, but better. The bootstrapper allows us to configure and interact with our application via several overridable methods and even provides an interface for defining startup tasks. Much of the magic of Nancy is enabled via an Inversion of Control container. While possible to define your own bootstrapper without an IoC, an Inversion of Control container affords us many benefits. It allows us to compose application components. In other words, Nancy uses an Inversion of Control container to create default implementations of view engines, startup tasks, model binders, the favicon, deserializers, and diagnostics conventions. But it also gives you the ability to replace or enhance these implementations via the same Inversion of Control container. TinyIoC is the default Inversion of Control container. It's provided by the Nancy framework. The Project Insight Wiki are available here. And just like other components in the framework, we are free to swap it out. On the Nancy site in the NuGet. org site, there are several Inversion of Control container adaptors available for Nancy.
Views and View Engines In this module, we will be exploring how to populate views with data from your Nancy application. In the introduction, we looked quickly at rendering a view. However, we displayed a static page. In the second module, we worked with pure data sending JSON back to our client but when we build web applications, we want dynamic views that are specific to the request, contextual data not just tabular data but data that enhances the experience of the user, and we want templated output. We want to be able to take the contextual data and put it into a reusable format. When working with views, we are concerned with 3 things. First, we are concerned with locating the file that represents the view, the file that contains the markup. Second, we are concerned with encapsulating the data that the view will need to render correctly. And third, we're concerned with using the view engine to tokenization to marry the data to the markup using the view engines specific syntax.