Sponsor: Do you build complex software systems? See how NServiceBus makes it easier to design, build, and manage software systems that use message queues to achieve loose coupling. Get started for free.
On one of my posts showing how you can use Nancy with ASP.NET Core, David Anderson posted the following comment
I came across some Nancy blogpost last week and got curious about it and so looked on internet for more information. I wanted to know why should someone use Nancy and why plain asp.net core is not sufficient. So far every place I look I see the same introduction, you know that one with ‘…super-duper-happy-path…’. But to be honest it’s still not clear ‘why’? What is it that someone can not do in ASP.NET Core which is ‘super-duper’ in Nancy? What is hard or missing in ASP.NET Core which is easy or available in Nancy? The need of such a framework on top of ASP.NET Core is very vage to me.I realized that I never really blogged about why I started using Nancy. I hinted at it slightly in my post about ASP.NET Core MVC Attribute Routing, but not in much detail.
MVC & Web API Routing
Like most, I primarily used ASP.NET MVC and Web API. When I got into creating more Web API’s, the first thing that started causing me trouble was routing. The convention based routing employed is to define your routes in the RouteCollection. This is the familiar default route that you might have used before. The primary issue I had with defining routes and route templates up front, was I to defined them closer to the code that was actually executing at a given endpoint. Route Attributes do ultimately solve this problem and from what I’ve read recently, this seems to be the common way most now define routes. However, I’m simply not a fan of attributes in this situation. I won’t get into the reasons why, as I don’t think starting an attribute war serves much purpose for this post.Nancy Routes
When I first seen how you defined routes in Nancy, I realized it was exactly what I was looking for.Routes are defined in the constructor of a module. In order to define a route in Nancy, you need to specify aMethod+Pattern+Action+ (optional)Condition.
They’re just endpoints…
When you look at a Nancy module, you could compare it to a MVC or Web API Controller, but it’s really nothing more than a place you can define HTTP Endpoints. This means you can use Modules as Controllers and develop using your familiar MVC pattern, or you could use them as Web API’s. You can have your endpoint do whatever you need and return whatever you want.Simple
Nancy by default is really simple to use. You need zero configuration to get started. Zero. Add a Nancy Module and you are off to the races. I’ve made a couple different posts on how you can use Nancy along side Web API in ASP.NET 4, and how you can use it with ASP.NET Core.ASP.NET Core
Back to the comment and the last sentence:The need of such a framework on top of ASP.NET Core is very vage to meNancy doesn’t replaces ASP.NET Core, but it could replace your need for ASP.NET Core MVC. With the application pipeline (middleware) in ASP.NET Core, this allows you to leverage many different components that serve different purposes all within your web application. For example you could use Nancy, ASP.NET Core MVC, Static File Server and Authentication.
You have now written two blog posts talking about Nancy and ASP.NET Core Attribute routing. In both you say you’re not a fan of attributes but do not explain why. When is the blog post about attributes coming? 😉
For me, I used it where some of our clients were constrained to .net 4.0 (yes there are some still running Windows Server 2003). It was the only way to properly self host MVC and API endpoints (yes Web API worked, but not with OWIN). As it happens, I didn’t get on well with the Nancy view engine, but the API, routing and everything else just worked.