根据我浅薄的经验，缓存、iframe、NoTalk 足矣
首先，是缓存，因为这个人人都会使，实施成本低，用了可以明显加快访问速度，降低数据库负担。
但是也存在以下几个缺点：
1：难以监控命中率。
通常的缓存有.NET 自带的cache、微软企业库的cache、memcached，数据库级别的查询缓存，一般小项目都是自带的cache，发展到一定阶段用微软企业库的cache，发展到分布式用memcached，缓存进一步精确细化会用到数据库级别的查询缓存，但是这些缓存都有难以监控命中率的缺点，开发团队技术较弱的根本就不知道命中率还可以监控。
2：难以在项目中控制缓存时间和缓存大小
大家可能会用各种集中控制缓存时间的办法和点子，但实际项目里面的缓存时间都是写代码时候拍脑子决定的，这里1分钟，那里1小时，都无从考证为什么要缓存这么长时间，二不恰当的缓存时间又会影响命中率。
.NET 自带的cache、微软企业库的cache 都无法限制要缓存的单个对象的大小，memcached默认1m，但是很人都把这个默认值改大了，因为大家无法控制自己要缓存的对象 到底有多大，也没有相关的工具能够测评要缓存的对象或实体有多大，所以经常出现加了缓存后cpu暴涨的的事（低命中率+反复序列化+读写缓存等待）==》高cpu
3：通常缓存是万能方法，那里都可以使用
缓存这个退头疼的问题就是他是万能的，任何地方都可以使用，开发的时候加上了，看着他的确加快的第二次的访问速度，项目里到处都是缓存，但是，我很少见，几乎没见过有人对整个项目的缓存做单元测试、压力测试、计算命中率，最郁闷的是当项目里到处都是缓存了，网站cpu又高，你始终找不到到底哪里是系统的瓶颈，去掉缓存没1分钟整个系统就迅速挂掉。
缓存从而彻底蒙蔽了开发团队的眼睛：数据库设计到底合理不合理，需不需要做横纵分拆、需不需要做主从镜像，那些需要建索引那些不需要，那些需要缓存、缓存多长时间，站点需不需要拆分，需不需要把那些页面单独拎出来做虚拟目录等等优化手段都需要找到系统瓶颈，但是现在你却找不到了，不是你不找，而是你无法在真实环境收集有效的信息。
面对孱弱的数据库，大家，大家只能增加web服务器和缓存服务器。。。
然后，是iframe。iframe就是嵌套页，他有什么好处呢，就是做外面页面的和做里面页面的彼此在服务器端互不干涉，在客户端也互不干扰，因此经常出现打开一个页面却发现页面的某一模块显示404错误，iframe就是页面补丁，当一支团队无法控制整个页面的质量的时候，就会才去给页面打补丁的方式，来处理页面的的展示，是一个队伍不思进取、变懒的开始，当然，也是分工明确，职责分明的体现，一般情况下，喜欢用iframe的团队做出的来动用户体验比较差，因为他们的js是在太弱了。
最后，NoTalk，将彻底让这支队伍在 沼泽中迷路，沟通表现在很多方面，代码、注释、文档、集体讨论。当一支队伍只有项目上线时间表,却NoTalk,NoTalk
NoTalk,NoTalk,NoTalk,NoTalk,NoTalk……………..我只能呵呵了