I haven’t done much reading about the “official” [patterns][1], like in the book [“Design Patterns”][2], but I’ve always understood patterns to be a concept more than something set in stone. I think someone once told me that design patterns are descriptions of things you already do, or maybe partially do, when you write software. They’re more descriptive than prescriptive you could say.
Anyway, in a few of the web-based applications I’ve written I’ve used this pattern that I’ve started calling the Context pattern. It’s probably more of a model than a pattern, as it’s comprised of a few components. It’s not quite fully fleshed out yet, but here are the basics of it (in fact I think I’ve heard of a pattern that someone called the delegator pattern, and it’s probably a lot like this, I should look it up):
[1]: http://en.wikipedia.org/wiki/Design_Patterns “Design Patterns Wikipedia entry”
[2]: http://en.wikipedia.org/w/index.php?title=Special:Booksources&isbn=0201633612 “Design Patterns ISBN info from Wikipedia”

All requests are handled by a single script (we use PHP almost entirely). This script creates a ContextFactory and asks it for a Context object corresponding to some key that gets passed in from the browser. So for example, if the user is looking at some main page and clicks on a link that’s labeled “Add Item”, perhaps the main script would be called with an “action=add_item” query string element.
The ContextFactory is responsible for evaluating the key that is passed in, evaluating it, and creating a Context object suited to handle the request. It then passes this Context object back to the caller, and is done.
This object implements the Context interface, which basically just has a process() method, so the main script calls that and is finished. In this model, you have several layers of responsibility, each clearly defined. The main script is responsible for doing the orchestration for the request, the ContextFactory is responsible for evaluating a key and returning a something to handle it, and the Context objects are responsible for exactly one action. This setup has worked very nicely for situations where you don’t need to maintain complex state in your application, but rather have a list of predefined “actions” that can be performed from a central control hub.
There are some drawbacks to this approach, like the fact that it gets a little difficult to maintain any sort of state (especially if the user decides that they want to get out of a particular multi-step action before it’s finished), but so far it seems to scale well, keeps code fairly clean (notice a bug while adding an item, you know just where to look to find it), and is at least a little object oriented ^_^.
For more info on patterns, here’s one good source [Portland Pattern Repository Wiki][3]
[3]: http://c2.com/cgi/wiki?PortlandPatternRepository “Portland Pattern Repository”