I am trying to coach some guys on building web applications. They understand and use MVC, but I am interested in other common patterns that you use in building web apps.
So, what patterns have you found to fit nicely into a properly MVC app. Perhaps something for Asynchronous processes, scheduled tasks, dealing with email, etc. What do you wish you knew to look for, or avoid?
Not that it matters for this question, but we are using ASP.NET and Rails for most of our applications.
I would most likely recommend some kind of Dependency Injection as well (Inversion of Control). Probably the single most important supplementary "pattern" to use.
This question is so open that it's hard to give a correct answer. I could tell you that Observer pattern is important in MVC (and for webapplication) and it would be a good answer.About all design pattern that exist are common in big web application. You will require to use some Factory to build complexe object and to access some section require some Facade.
If you want more "tips" or good practice instead of design pattern, I would suggest you to use IoC and the use of good Framework instead of starting from scratch. I can suggest you to explain the benefit of having a good ORM engine to drive you persistance layer faster too (usually can come from the Framework too).
Don't look at it from the aspect of what patterns to use with your development approach, but look at it more as how to apply patterns on a problem-by-problem basis. The architectural decisions made for the project provide just as much indication of what patterns to use as other people's experience will dictate.
That said, I have found that I am a fan of the Provider model for having multiple choices to accomplish a single task with ease of deployment added in. Also, the Unit of Work pattern is great for setting transactional boundaries. Largely, though, the architecture and business needs dictate the approach that is taken for any given code change or new development.
As much as I love patterns, I always fear seeing them overused. I have personally seen people that have used them just for the sake of using them, and it has actually made the code harder to maintain and more tightly coupled than it should have been. Also, it is good to know both sides of the patterns argument. A good pattern knowledge should be rounded out with (often considered a pattern, on its own) anti-pattern knowledge, as well.
Once you get into MVC, it can be worthwhile to explore patterns beyond the "Gang of Four" book, and get into Martin Fowler's "Patterns of Enterprise Application Architecture."
The Registry pattern can be useful to make well-known objects available throughout the object hierarchy. Essentially a substitute for using global data.
Many MVC frameworks also employ the Front Controller and the Two-Step View patterns.
The "Model" in MVC is best designed as the Domain Model pattern, although some frameworks (led by Rails) conflate the Model with the ActiveRecord pattern. I often advise that the relationship between a Model and ActiveRecord should be HAS-A, instead of IS-A.
Also read about ModelViewController at the Portland Pattern Repository wiki. There is some good discussion about MVC, object-orientation, and other patterns that complement MVC, such as Observer.