Here’s a REST-y kinda controller I did for “FubuDinner” a year ago when I was playing around with rewriting NerdDinner in Fubu:
https://github.com/chadmyers/fubudinner/blob/master/src/FubuDinner.Web/Actions/Accounts/RegisterAction.cs

Note that it has a “Query” and a “Command” method that corresponds to GET and POST respectively.

Notice that Joshua’s post that I linked above is over a year old. And this post is even older. It was nearly impossible in ASP.NET MVC to do what we have been able to do naturally in FubuMVC since the beginning. It looks like only now (2+ years and 3 versions later), they’re able to talk about single-action controllers. I wonder if it’ll take another 2+ years and 3 versions before they can do even half of all the myriad of ways we can define actions in FubuMVC :)

So yes, Front Controller sits in front and dispatches a bunch of Command Pattern commands. Front Controller != Command, but uses commands.

Repository is something different as it is intended primarily for database access (at leas the P of EAA version). Though in FubuMVC there is an element of repository-type searching through all model to match routes to actions to views. But that all happens at initialization-time, not at run-time in FubuMVC. In ASP.NET MVC, it happens at run-time (figuring out which controller to execute for a given route).

Even just having Controller’s as actions with a Get/Post method is really a great start.

Not really true. In Java, this pattern has been around for donkeys years. For a good example, take a look at WebWork, which powers the Atlassian apps like Jira etc.

If you’re interested in another (drastically) different approach to the issues of controller/action composition and how endpoints are exposed from the server to the client (which is a big chunk of what the controller/action mapping convention that is so popular in the “non-stupid” ASP.NET frameworks these days is about), you should really check out the marvelous Ruby-based Sinatra (http://www.sinatrarb.com/) framework. The excellent stuff going on in that framework is what is driving my current experiments in ASP.NET.

Try all you guys want to make MVC “prettier” and more intention-revealing in C#. The problem, though, is this: You’re stuck using a crappy, general-purpose language to try and elegantly express what is really better expressed in other ways. And I don’t think “But! But! Tooling!” is convincing enough of an argument, longterm, to justify this self-flagellation.

If you look at what the current state-of-the-art is with regard to web apps (rich js client, rich domain), you can pretty much see that the job of the actual web framework (grossly over-simplified: map data to/from the client/server) is 1) narrowly-scoped and 2) highly optimizable.

Years of pounding the ideas of loose-coupling, SRP, DRY, etc into our heads has given us web applications mappings that are, when you get down to it, pretty damn anemic. All the data-access, behavior, etc lives in the domain or is abstracted out into the app service layer. We’ve (hopefully) broken the cycle of abuse of using retarded server callbacks in rendered views in favor or much more easier testable js (javascript controllers/views, anyone?). We’re using view engines that don’t suck to compose tighter, less-entangled rendered views (that are becoming pretty anemic, themselves, as the js side of things gets more of a share of the the action). So what about what’s left over?

What I’m saying this: The stuff we code at the web framework level (controllers, actions, behaviors, etc) is pretty damn rote, all in all. In other words: A perfect candidate for a DSL.

Enter things like Sinatra (or my own solution, which is still incubating and thus not heavily pimped, here).

You’re gonna be stuck with chestnuts like overloading constructors of a class to model actions as long as you remain in the BDSM box of C# as your only way to do this kind of thing (to get the tired Matrix cliche out of the way: it’s a prison for your mind).

The domain requires a rich language to be expressed fully; use C# there. The client requires a rich language to be expressed; go ahead and use js or whatever for that, as well.

But the web framework? Seriously. In statically typed .NET, the most complicated things it does is 1) deliver dependencies to 2) do query/command tasks to ultimately 3) map data to/from the client/server. period. Item 1 isn’t that big of a deal in Ruby because you can monkey-patch that stuff away and bait-and-switch dependencies when testing. Oh yeah, and the web framework probably manages your security and session baggage, as well.

Anywho, I’ll get off my soapbox, now. I just think that the entire discussion up until this point is predicated on the assumption that the job that web frameworks do is something that really *requires* verbose, convoluted solutions like those that’re prevalent in the debate. We can do better, in my opinion.

yes it’s somehting that has been in OR for a while, the idea that resource types (what snooze calls strongly-typed URLs) are the things that drive URIs.

That said, as you correctly point out, by default in OR the action semantics is based on the resoure type and the http verb, and from what I understand, your proposal carries the operation semantic as part of the model definition (your EditProduct).

Laribee suggested the idea of using profiles in OR to let you define various programming models, and is something that i’m investigating. The latest version of OR includes a new way of defining / discovering / executing operations, and so this scenario, like a few others (around controllers with only one methods and public properties for resolution by binders and codecs) should be very easy to support.

If there’s demand for it, it’d be easy to make such a profile to run fubu on top of OR instead of asp.net, and get the best of both worlds :)

Seb