缓存是Web应用程序中的重要部分，但没有一种神奇的解决方案适用于每个项目。在应用程序正常运行之前进行优化通常不是一个好主意。在问自己应该在哪里实现缓存层之前，第一步是确保您的应用程序可以正常运行（即使速度很慢）而不需要任何缓存优化。
当完成第一步后，可以开始对应用程序进行分析，列出似乎使用了大量资源（可能是CPU、内存、I/O、数据库访问）或需要很长时间才能完成的功能列表（通常是由于相同的症状）。
一旦您有了认为可以使用缓存系统进行优化的功能列表，就需要问自己两个问题：
“如何同时改善所有这些功能”（宏观视角）：对于这个问题，一个明显的答案通常是数据访问缓存。如果您总是获得相同的返回数据，那么通常不希望反复向数据库服务器发送相同的查询。因此，在缓存中存储这种类型的数据，并赋予聪明的生命周期，永远都是一个好主意。
“如何改善每个功能”（微观视角）：这很棘手，您需要非常了解自己的应用程序才能找到答案。有些数据可以缓存，有些不应该缓存，有些必须不能缓存。调试器和分析器通常是此步骤的绝佳工具，因为它们可以帮助您确定为什么功能很慢，并为您提供如何进行优化的提示。
您将要找出的优化可能与应用程序的任何层（表示、业务逻辑、数据）相关，但这并不意味着您应该全部实现它们。有几个重要的事情您应该考虑：
一旦你得到了这些问题的答案，就可以与项目经理、同事甚至不与你共事的人谈论这个问题。拥有中立的意见以及非技术性（或少技术性）的意见是好的。与这些人交谈应该可以帮助你弄清楚哪些应该做和哪些不应该做。
此时，你应该已经有一个相当明确的优化清单，你已经反复思考过了，并且在编码和测试它们方面也没有任何问题。
缓存是一种性能优化方式，应该在瓶颈处使用。通过三次测量来确定瓶颈位置，然后再确认一次。
当你缓存数据时，要注意数据的松散一致性，例如，您不希望缓存您的所有股票交易应用程序。
数据层 - 在此层以上的所有层都不需要知道数据的来源。我也只会缓存那些不太容易变化的数据，或者包括一些过期策略。
缓存：在数据访问层实现，由业务逻辑层访问。
这意味着您必须仔细注意缓存过期的情况。
这是我首选的解决方案，如果需要，您可以添加超时、清除等功能。或者使用memcached或Microsoft Enterprise Library Caching Block，但它们通常过于复杂。
我不能代表ASP.NET具体的事情说话，但我通常发现你可以在每个级别上进行缓存。您的数据层将缓存数据响应，您的表示层可能会发现需要缓存生成的表示元素（例如用户特定的样式表），等等。在大多数情况下，数据层是最重的缓存用户，如果需要，其他层将包括对象缓存。
最困难的部分是正确地使缓存失效。在部署期间，陈旧的缓存是一个主要的头痛。确保弄清楚如何管理每个缓存对象的生命周期。基于需求的LRU缓存可用于缓存静态元素。然而，大多数数据缓存将需要明确的生命周期，无论是基于过期计时器还是与某种用户会话相关联。
