

ASP.NET You're doing it Wrong. An Introduction to Nancy - invalid_arg
http://mat-mcloughlin.net/2013/08/20/aspnet-youre-doing-it-wrong-an-introduction-to-nancy.html

======
seanmcelroy
The article title is pretty misleading. NancyFX looks very succinct, but it
solves much smaller scope of problem than ASP.NET MVC does. The only notable
comparison he makes between NancyFX and ASP.NET MVC is routing -- while the
level of indirection in the RouteManager and the folder structure conventions
of the default one provided in ASP.NET MVC, the purpose of that is to give
enterprise applications an extensibility point. If you don't need all the ways
you can customize ASP.NET MVC, sure go with a simpler framework. But there's
nothing "doing it wrong" about using ASP.NET MVC if you need the services it
provides.

~~~
philliphaydon
"the purpose of that is to give enterprise applications an extensibility
point"

No its not.

"If you don't need all the ways you can customize ASP.NET MVC"

Nancy is pluggable at pretty much any point. You don't like the way routing
works in Nancy, plug it. Don't like the base module, plug it.

Nancy is far more extensible than WebAPI or MVC.

Having said that, anything you can do in WebAPI / MVC you can do in Nancy, and
anything you can do in Nancy, you can do in WebAPI / MVC

Nancy just has a nicer API.

~~~
jf22
>Nancy just has a nicer API.

In your opinion.

A lot of older developers don't like the Func<>iness of some of these newer
frameworks. Just something to consider.

------
skrowl
I think this guy has never heard of Web API ([http://www.asp.net/web-
api](http://www.asp.net/web-api)). He's saying MVC is bad, then he writes code
that just returns serialized data instead of views.... which is exactly what
Web API does.

~~~
corresation
Isn't this what WCF does as well? WCF will happily interact with JSON clients,
and make spinning out services blissfully easy and efficient.

~~~
philliphaydon
Hahaha, have you actually used WCF? You may as well just use SOAP. You wont
end up slitting your wrists.

WCF's only benefit is TCP bindings. If you're doing any HTTP stuff, stay clear
of WCF.

~~~
corresation
I'm wondering if you've ever actually used WCF, or if you're simply incredibly
ignorant about how to use it (why understand existing systems when you can
recreate them -- poorly -- yourself), as creating a JSON-friendly web service
in WCF is absolutely _trivial_. Through some very large scale systems I have
had absolutely no issues, whatsoever, with it.

Your issues with it might have more to do with you.

Odd that the two single replies I got are a couple of bulldogs desperately
shooting any alternative to this submission down.

~~~
philliphaydon
Currently in the process of ripping out WCF and replacing it with
ServiceStack. Because WCF is such a pile of shit. If you seriously think WCF
is good, and 'trivial' then you're clearly a MS fanboy who've never tried
alternatives.

I used to be like you, think WCF was the bee's knees.

WCF promote poor service design, in an untestable manner, has no real support
for DI, has terrible configuration, unhelpful exceptions, faults, message size
limitations that cause headaches, horrifically slow. The only benefit to WCF
is TCP endpoints. End of story.

~~~
corresation
_you 're clearly a MS fanboy _

Um...okay. That says enough. End of story.

~~~
TheOsiris
I've done my fair share of WCF development, and I can tell you without
reservation that it just BLOWS!

I'm glad MSFT is moving away from that.

------
ktavera
I started moving a large API we had built on MVC4 over to using WebAPI 2 beta
and the attribute routing is amazing. Nancy looks to have similar conventions
as far as routing goes but one thing I just couldn't get working properly was
authentication. With WebAPI I found it more intuitive to have
[SomeCustomAPIAuthenticationAttribute] on controller class and have it look
for either an active session (for our browser javascript ajax calls) or if it
has none then for an ApiKey (for our mobile apps) in the post data and look up
to make sure the api key is valid.

Nancy is cool and i'd definitely consider using it in the future but for now,
it was easier to port over our api from MVC4 to a much more familiar
structure.

~~~
philliphaydon
Nancy uses extension methods in placement of Attributes.

Forms auth is done by calling this.RequiresAuthentication(); you can implement
an extension method to do an ApiKey check in about 5 lines of code :)

~~~
ktavera
Thanks for that! I'll have to play around with it again.

------
mcgwiz
How about a demonstration of something of real-world significance?

\- content negotiation (basic building block of hypermedia APIs),

\- authentication (and ensure SSL is used when authenticated),

\- most importantly, HTTP caching, where

\-- unauthenticated users get cached content, authenticated users don't,

\-- vary on representation negotiations (media type, encoding, and language),

\-- cache is located on server and in browser.

In other words, take basic advantage of HTTP to improve security and
performance. Taken together, the requirements listed above comprise a problem
of only moderate complexity, and are fundamental to flexible, high performance
web apps. Accomplishing it in ASP.NET MVC/Web API is painful and relies on the
inconsistent, malfunctioning, horrifically designed ASP.NET response caching
module.

Show me a framework that does the above and makes it reasonable to build
hypermedia APIs, and you've got yourself a convert.

~~~
tegeek
There you go [http://servicestack.net](http://servicestack.net)

~~~
mcgwiz
Thanks for the pointer. Will dig in.

------
SideburnsOfDoom
Nancy is cool. Currently trying ServiceStack
[http://www.servicestack.net/](http://www.servicestack.net/) which is also
great at serving up json endpoints.

~~~
ktavera
Agreed, it looks like a promising framework as an alternative to MVC4/5

------
anko
[http://www.sinatrarb.com/](http://www.sinatrarb.com/) ?

------
graycat
I don't 'get it': I'm developing a Web site, my first serious one, and using
the standard Microsoft software tools Windows, IIS, Visual Basic .NET,
ASP.NET, ADO.NET, SQL Server, and some of the rest of .NET, e.g., TCP/IP
sockets.

For entering the code, I am using my favorite (programmable) text editor and
believe it is working very well. Otherwise I use some scripts I've written in
my favorite scripting language.

To do this development I read through about a cubic foot of books and 4000+
Web pages of documentation, nearly all from Microsoft's Web site.

For the development I struggle some with 'scope of properties' in CSS (which
apparently is nearly never discussed) and much of the documentation, but
otherwise from the server farm architecture to the computing to be done down
to the lines of code and documentation, there are no problems. E.g., for a
single Web page, say, X, there is a file X.ASPX, and it has some options, some
static HTML and CSS, some 'event handlers', e.g.,

    
    
         Sub Page_Init
         Sub Page_Load
         Sub Page_PreRender
         Sub Page_Unload
    

some Visual Basic code, a lot of use of classes from ASP.NET, ADO.NET, etc.,
and some include files for CSS, functions, classes, etc. Fine.

And I don't have even as much as a weak little hollow hint of a tiny clue what
MVC is or why I should want or need it. The explanations of just why I should
want MVC look to me as burdensome and totally meaningless distinctions and
constructions for no good reason. Same for a 'framework'. Same for Nancy and
everything else in the OP.

E.g., the OP talks about GET and POST "methods". I don't do those things --
IIS and ASP.NET handle those for me. If I want the actual post data, then it's
available to me via some ASP.NET classes. But the code I write doesn't deal
very directly with GET or POST.

And have I found no good explanation of why I shouldn't just continue as I am.

I don't have a clue what OP is talking about.

My guess is that MVC, Nancy, etc. are for programmers with backgrounds in Web
development on Linux who want to program on Windows and there use programming
tools and techniques they used on Linux instead of just the usual Windows IIS,
ASP.NET, etc.

I've already read a cubic foot of books and 4000+ Web pages of documentation,
and my work is going fine; why should I junk my work to date, read a lot more
documentation, involve myself in more overhead of tools instead of just going
my real work?

More documentation can have errors; more tools can take me farther from the
real data and can have bugs.

Am I doing something seriously wrong?

~~~
untog
_E.g., the OP talks about GET and POST "methods". I don't do those things --
IIS and ASP.NET handle those for me._

You might be absolutely fine not knowing those things, but at some point down
the road you are going to be lacking some essential knowledge of how HTTP
works. To put it simply: _everything_ \- Ruby, PHP, ASP.NET, you name it -
uses GET and POST requests underneath it all. Learning about them would be of
great benefit to you in the long term.

A slightly inaccurate analogy: you can make a perfectly functional web site
with Dreamweaver, and not touch a single HTML tag. It'll work fine, until it
doesn't, and then you're going to be in a lot of trouble. Given that you don't
know what's going on underneath Dreamweaver's GUI, your only option will be to
keep hitting 'undo' until it works again.

 _Same for a 'framework'. Same for Nancy and everything else in the OP._

ASP.NET WebForms is a 'framework', too. They're just different frameworks.
WebForms, as the name suggests, is particularly good at creating forms- it has
numerous abstractions to help you maintain state. It's great for intranet data
gathering/presentation stuff. But the pages are very, very heavy, loaded down
with code that never gets used. So it has pluses and minuses. Just like MVC
and Nancy.

~~~
SideburnsOfDoom
ASP.NET WebForms is absolutely a framework and a heavyweight one. It tries to
hide the details of http and html as the grandparent says. I for one don't
care for that, I prefer a lighter weight framework which works with http
rather than hiding it. ASP MVC is lighter weight than webforms, and Nancy or
ServiceStack is even lighter weight.

Some things like making an endpoint that servces json and xml responses is
almost trivial on Nancy or ServiceStack, easy in ASP MVC with WebApi, and a
pain in webforms.

~~~
graycat
Thanks. As I wrote above, as far as I know, I'm not using WebForms and am just
using basic IIS and ASP.NET.

From what I understand, what I'm using is _lighter weight_ than MVC or
anything else being discussed here. So far, I see no problems with what I'm
doing.

E.g., for the MVC _architecture_ , I have a server farm and software
_architecture_ , and it's simple and more than enough.

~~~
SideburnsOfDoom
> as far as I know, I'm not using WebForms

If you have "event handlers" like "Page_Init" in a .apsx.vb file then you are
using web forms. No other framework has these. They were an attempt in the
late 1990s to make the web look like winforms. it worked, to a degree.

> what I'm using is lighter weight than MVC

I doubt it.

> I see no problems with what I'm doing.

That's a different question; I'm sure what you're doing is workable.

~~~
graycat
Thanks! I needed that!

