一旦你进入MVC，探索除了“四人帮”书中的模式，深入了解马丁·福勒的《企业应用架构模式》可能是值得的。

注册表模式可以方便地在对象层次结构中提供公共对象，并可以替代使用全局数据。

许多MVC框架还采用前端控制器和两步视图模式。

"MVC"中的“Model”最好设计为“Domain Model”模式，尽管一些框架（由Rails领导）将“Model”与“ActiveRecord”模式<合并>。我经常<建议>在Model和ActiveRecord之间的关系应该是HAS-A，而不是IS-A。

也可以在波特兰模式库维基上阅读关于模型视图控制器的内容。这里有一些关于MVC、面向对象和其他补充MVC的模式（如观察者模式）的很好的讨论。

这个问题很开放，很难给出正确的答案。我可以告诉你，在MVC（和Web应用程序）中，观察者模式非常重要，这将是一个很好的答案。几乎所有现有的设计模式都在大型Web应用程序中很常见。您需要使用一些工厂来构建复杂对象，并且要访问某些部分，则需要使用一些Facade。

如果你想要更多“技巧”或者好的实践，而不是设计模式，我建议你使用IoC和好的框架，而不是从头开始。我可以建议你解释一下拥有一个好的ORM引擎来加快持久层速度的好处（通常也可以来自框架）。

不要从使用开发方法的模式的角度来看待它，而是更多地从逐个解决问题的角度来考虑如何应用模式。为项目做出的架构决策提供了与他人经验同样多的使用模式的指示。

话虽如此，我发现我喜欢提供者模型，因为它可以提供多种选择来轻松完成单个任务，并增加部署的易用性。此外，工作单元模式非常适用于设置事务边界。然而，总的来说，架构和业务需求决定了针对任何给定的代码更改或新开发所采取的方法。

尽管我喜欢模式，但我总是担心它们被过度使用。我个人见过某些人只是为了使用它们而使用它们，实际上这使得代码比它应该做的更难维护且更紧密耦合。另外，了解模式争议的两面也很重要。好的模式知识应该包括（通常被认为是一种模式）反模式知识。

我最可能还会建议使用某种依赖注入（控制反转）。这可能是使用的最重要的补充“模式”。