I’m reluctant to get involved in this – but I feel like there’s another side to this story which is worth considering.

Since it was first presented at altnetconf – the decision to require users¹ to have to specify which methods on controllers are available to be routed to ([ControllerAction]) and which view (RenderView()) to render has come in for a lot of criticism.

Lots of the brightest and best minds in the .net world are screaming about this in various forums. Claiming that it violates:

• the DRY principle
• convention over configuration
• best practice in other frameworks
• commonly accepted laws of physics

Not one of the people complaining is going to use this framework vanilla. They are going to add their own layer of behavior over the top. It’s been designed to make it easy (trivial in this case) to extend and change the policy.

Sane defaults are really important for frameworks. Yes they get in the way of power users. Yes it normally takes a power user 10 minutes to work around them and add that piece of code to their toolbox from then on.

I don’t know how many people were following the emergent rails community back in 2005 when the Google Web Accelerator was released – but many of them (including the smartest² ) got a salient lesson in GET idempotence. (i.e. GET Order?id=23&action=delete – should never delete anything).

Here was a situation where the framework (rails) came with not so safe defaults and bad example code which encouraged doing the wrong thing. These days – rails has absorbed this lesson so completely that it could be described as a REST server and in some ways leads developers into following best practices for web apps by default.

I really don’t understand what the huge deal is here? This seems as clear cut to me as the built in RequestValidation in ASP.NET or automatically escaping SqlParameters for SQL injection. Sure – if your a power user it can be a pain – but it takes 10 seconds to turn off and then your responsible when your site get p0wn’d.

It’s not like ControllerBase is sealed.

1. by default – but easily modifiable
2. or is that loudest?

At the time – the best web architecture I knew of was the ArsDigita Community System (still available and maintained as OpenACS). What Oren is describing sounds similar in many ways.

The ACS architecture is based on the days when Oracle and TCL were good options for building web based systems…. but the underlying design is still very very good (e.g. it was the first place I every saw the Party pattern). They were focused on designing good data models and separating concerns.

They have the following available in their kernel:

• Parties, Users and (nestable) groups
• A permissions system which supports per “object” (think row) permissions.
• A package manager which allows you to install (and remove) modules of functionality into an existing system (including schema changes, new routes etc). e.g. adding a e-commerce, blogging or threaded discussion module is a matter of clicking in a web ui.
• Scheduled tasks

This thing was and is pretty scalable (it runs the photo.net community).

It’s over 10 years old still a source of good ideas. I recommend taking a poke around their documentation and seeing what you can learn.

(I remember reading once that Philip Greenspun – the original ACS designer was asked by Microsoft to build a new version while the .net framework 1.0 was in development as a showpiece. For some reason he didn’t but I always felt that it was a shame this never happened).

Here’s a couple of great quotes (It’s worth noting that he’s talking about large projects):

Not everything is going to be well designed.

You may have a part [of a system] which is not complex – or is just straight forward data collection. You’ve got a lot of screens , a lot of fields. You’ve got to put it into the data base and do a simple report on it.

Don’t spent a lot of effort modelling these things. Just find some simple technology that’s good at that stuff.

The idea that the entire system is going to be based on an object oriented model is I think is a highly questionable assumption.

It’s a really interesting perspective – and a great antidote to some of the discussion at the moment which almost treats DDD as a silver bullet.

Anyone who’s feeling guilty because they don’t have their solutions structured into Core, Model, Services, Presentation, UI layers – or even worse is using a SqlDataSource control in their app – should watch it. It’s an excellent dose of pragmatism.