官网地址

官网简介

Nancy is a lightweight, low-ceremony, framework for building HTTP based services on .NET Framework/Core and Mono. The goal of the framework is to stay out of the way as much as possible and provide a super-duper-happy-path to all interactions.

Nancy是一个轻量级的低成本框架，用于在.NET Framework/core和Mono中构建基于HTTP的服务。框架的目标是尽可能的避开HTTP细节，为所有的交互提供一个高度抽象及易配置的使用方式。

Nancy is designed to handle DELETE, GET, HEAD, OPTIONS, POST, PUT and PATCH requests and provides a simple, elegant, Domain Specific Language (DSL) for returning a response with just a couple of keystrokes, leaving you with more time to focus on the important bits.. your code and your application.

Nancy可处理DELETE、GET、HEAD、OPTIONS、POST、PUT和PATCH请求，只需要几行代码就能提供一个简单、优雅、领域特定语言(DSL)的返回，让你有更多的时间去关注代码和应用程序重要的部分。

开发者反馈

Reddit地址

Why should I (not) use NancyFx

Disclaimer; I’m part of the Nancy team and use it daily ;)

利益相关：Nancy开发团队的一员并将其应用于日常工作

Here are some of my top arguments on why you should use it:

使用Nancy的强力依据：

Convention over configuration. The framework gets out of your way and lets you concentrate on your code, rather than setting up and configuring the framework itself. It comes with sensible defaults to get up and running quickly and once you move towards a more advanced setup, it’s easy to customize.

约定优于配置：Nancy使你能将精力从建立及配置框架上转移，使你专注于代码本身。默认配置能够快速建立工程并使其运行，通过简单的配置即可完成高级功能的定制。

Dependency Injection everywhere. At the core of the framework sits an IoC container (might be a bit controversial). This means that you configure your application’s composition in a central place, the composition root (in Nancy’s case, the bootstrapper). Nancy has official bootstrappers for the most popular containers in the .NET community today, like TinyIoC (default), Autofac, StructureMap, Unity, Windsor and Ninject. There are also community maintained bootstrappers available.

集成主流依赖注入组件：控制反转模块作为框架的核心（此点有争议），意味着应用程序的组件需要在组件的核心（Nancy中的bootstrapper）集中处理。Nancy原生支持社区中主流的容器有：TinyIoC (默认)、Autofac、StructureMap、Unity、Windsor以及Ninject。还包括社区维护的其他控制反转的引导。

It’s host-agnostic and runs anywhere. The CI process builds the framework agains Mono to make sure it can run in all kinds of environments. It’s also built to be host-agnostic, which means that it pretty much runs anywhere, like IIS, Apache, nginx, FastCGI and self-hosted. Here are some hosts that are supported by Nancy:

  • Self-hosted - using HttpListener
  • System.Web - running on IIS (Express)
  • WCF
  • OWIN - This is the most versatile, recommended, hosting model.

支持多种托管方式：持续集成管线会在Mono环境进行编译，来确保其能够在所有的环境中运行。并且被构建成意味着在任何环境都能够良好的运行，例如：IIS，Apache、nginx、FastCGI以及自托管运行。下述列表为官方支持的托管方式：

  • 通过HttpListener进行自托管
  • 通过System.Web托管于IIS（及Express）
  • WCF
  • OWIN - 受到广泛欢迎的托管模型

Testing. Since the framework is built independent of a HTTP host, the framework can be “spun up” in-memory, which makes testing super easy. Take a look at testing your application.

测试：作为不受HTTP托管服务支配而构建的框架，框架可以在内存中进行迭代，使测试变得更加容易。关注并测试你的应用吧。

Great community. The documentation might be lacking in some places, but where it lacks in documentation, Nancy makes up for in community spirit. The docs are a GitHub wiki that anyone can edit, there’s good support in the GitHub issues and there’s a great JabbR chat-room where people hang out 24/7. The framework itself has over 200 contributors.

伟大的社区：缺少的不是文档，而是文档的精神（此句乱翻的）。Nancy通过社区来解决文档的问题。文档托管于GitHub wiki使每个人都能够进行编辑，并在Github的Issue中获得支持。在JabbR聊天室能获得7x24小时的支援。Nancy框架的贡献者已超过200名。

I’m not sure I buy the “hard to ramp up new hires on Nancy” argument. If anything, it should be easier for newbies, since it requires little knowledge of the framework itself to produce value. There are books, a Pluralsight course, lots of blog posts and talks to help you out. I’d also argue that if you’re up and running with Nancy, it’ll be easier to grasp some of the new ASP.NET 5 concepts, since they’re pretty much “borrowed” from Nancy (and 3rd party frameworks).

我很难认同“不易雇佣具备Nancy技术栈的雇员”这个观点：任何东西都应对新手友好，因为需要对框架的本身有一定的了解才能产出价值。书籍、Pluralsight的课程以及大量的博客都能帮助你度过难关。我同样认为了解并使用Nancy将会使你更加了解ASP.NET 5中设计思想，因为这些新特性很多都是从Nancy（及其他第三方框架中）“借鉴”来的。

BTW, Nancy was listed under “adopt” in ThoughWorks’ Technology Radar in May 2015 and several large applications and sites run on it, like Octopus Deploy and JabbR.

顺便一提，Nancy已在2015年5月被ThoughWorks’ Technology Radar名录收录，Octopus Deploy及JabbR等若干大型应用及站点基于Nancy运行。

PS：TECHNOLOGY RADAR收录值得关注的技术、工具、平台、语言/框架。

Positive

Nancy seems to be the only stable alternative HTTP framework for .Net, others have come and gone. Web API seems dominant because you knows its from Microsoft.

在.NET平台各种HTTP框架出现又消失，Nancy硕果仅存。Web Api之所以出于支配地位仅仅因为其来自微软。

For me I prefer Nancy over WebApi as its much simpler, its actually enjoyable and you don’t find yourself fighting something once your app becomes complex and you need that little something to just work.

对于我来说：因为Nancy足够简单，我更倾向于它而不是WebApi。使用Nancy是一种享受，使我不必与变得日益复杂的应用进行斗争。

Also bear in mind ASP.Net 5 has taken a lot of influence from nodejs as well as Nancy so I’d rather use something that is influencing rather than influenced.

ASP.NET 5的思想来自于nodejs及Nancy，因此我更关注具有影响力的框架而不是受影响的框架。

Avoiding 3rd party libraries means you have very few options. Nancy is an alternative to aspnet mvc/web api . I’m using it because is a bit more flexible than mvc 5 and much ligther. Btw, every time you’re using json.net ( you know, the one installed by default by the mvc template) you’re using a 3rd party lib. Using a DI Container which is not Unity? 3rd party lib also. Using a micro orm like dapper? 3rd party again. The modern asp.net web app is using a lot of non MS libs. And a lot of it is open source and based on my experience, a lot of the libs are better designed with better quality code than MS’s offering. Asp.net mvc 6 and asp.net 5 itself is heavily inspired from 3rd party libs. Since asp.net is open source now, you’re using ‘official’ dot net code not written by MS. tldr; Don’t fear 3rd party libs, you’re already using them.

避免使用第三方组件库意味着更少的选择权。Nancy是asp.net mvc/api的替代品。我使用它的原因是因为比mvc 5更加轻量柔韧。 顺便一提，当你每次使用json.net时，（mvc模板中默认组件），你在使用第三方组件。使用Unity以外的依赖注入工具？同样是第三方组件。使用像dapper一样的微型orm映射工具？还是第三方组件。 现在的asp.net web 应用正在使用非微软系的依赖项。根据我的经验，其中的大多数都是开源项目。很多依赖项提供了比微软更好的设计及代码质量。 Asp.net mvc 6及asp.net 5自身已经重度依赖第三方类库。自asp.net开源起，所谓的官方dot net code并不是微软写的。 因此，不要畏惧使用第三方类库，你早就开始用了。

You should use it over an MS-provided solution because if we let Microsoft trample all over every corner of .NET, we will never have a healthy ecosystem like…basically every other language out there right now. .NET has historically been “okay let’s fire up visual studio and make a webforms site with that weird ms-jquery thing” workflow where everything you could possibly need has been provided by MS for better or worse. We seem to be entering a cross-platform, cross-editor, nuget-package-heavy era where you can use industry standard tools instead of whatever solution MS has put to market. I can have as good an experience writing a Nancy site in Atom on Linux as I could on Windows with VS these days with things like omnisharp. I’ve used both Nancy and ASP vNext - I have no strong opinions about which you should use. I prefer Nancy just because that what I’ve happened to use the most. Luckily, as I mentioned above, things seem to be getting better. But if everyone had the attitude of “well I’ll just use whatever MS has provided me with” the community and ecosystem can never survive.

应该使用Nancy取代微软提供的解决方案，理由是如果让微软把.NET所有的资源都踩在自己脚下，就永远不能获得健康的生态系统，对比一下其他语言的现状就能找到答案。 早期的dotnet是：“好吧，咱们装个Visual Studio然后通过微软奇葩的jquery完成一个webforms的项目”，工作流中所有你可能遇到的一切不管好坏都已经被微软准备好了。 我们似乎进入了一个跨平台的、跨编辑器的、nuget包依赖的时代，因此可以使用工业标准的工具来取代微软投放到市场中的解决方案。在Linux+Atom编辑器+ominisharp分析工具就能得到Windows+Visual Studio的开发体验。 幸运的是，事情在变得明朗。但是如果每个人都抱着“我就只用微软提供的组件”这种态度，那么.NET的社区及生态系统将不复存在。

What I don’t like is that Microsoft’s various tools and frameworks are also sales tools. Hanselman goes, “Look how easy it is to create a great web app using EF, MVC with strongly typed views, and ASP.NET Identity!” Then the dev manager goes, “Oh yeah! That’s what we need! We’ll have this stuff done in no time!” Then it doesn’t work so well: IIS is a hog, EF generates garbage, etc. This is not an argument for or against non-MS frameworks. It’s merely encouragement to not base your decisions on the ease of a tutorial. In other words: it’s not about the ecosystem. It’s about people making lazy decisions.

“快来使用EF、MVC以及强类型视图构建一个ASP.NET的站点多么轻松！”然后开发经理跟风：“对对对！这就是我们想要的东西！” 然而却不尽如人意：IIS、EF产生的垃圾等等等等。 这不是鼓励你使用非微软系框架的论据，而是告诉你不要因为具备简单的教程而草率的下决定。 换句话说：其只取决于人们的草率决定，跟生态无关。

Negative

I was using NancyFx a couple years ago, and I haven’t touched since. My gripes from where it was then:

  1. constantly shifting api breaking all sorts of stuff.
  2. not great documentation. Again, that was about 2 years ago. Since then the documentation has improved quite a bit. But I’m not sure about the api stability. It helped that my coworker did the PluralSight videos.

几年前用过Nancy框架，但至今没在碰过 两点问题：

  • 不断变动的API破坏了原有的规则
  • 操蛋的文档

不过这是两年前了，最近虽然文档的质量有所提升，但我并不能保证文档的可靠性。但他却帮助了我的同事来完成PluralSight的教学视频。

However, my proposed counterargument is simply that while you may be comfortable for it, any other developers that come after you will have no idea WTF is going on because it is a completely nonstandard system. Thus you make for one hell of a maintenance burden.

我的观点正好相反：当你正享受Nancy带来的惬意时，其他后加入团队的开发者会对非标准的系统无从下手。因此会对项目的可维护性造成致命的隐患。