我没有使用任何缓存机制，并且想知道在以下情况下我在.net世界中的选择是什么。
我们基本上有一个REST服务，其中用户传递类别的ID（思考文件夹），并且此类别可能有很多子类别，每个子类别可以具有1000个媒体容器（思想文件引用对象），其中包含有关以下内容的信息可能位于NAS或SAN服务器上的文件（在这种情况下，文件是视频）。这些类别之间的关系与一些权限规则和有关子类别的元数据一起存储在数据库中。
因此，从UI角度来看，我们有一个惰性加载的树控件，该控件由用户通过单击每个子文件夹来驱动（以Windows资源管理器为例）。他们进入视频文件的URL后，便可以观看视频。
随着系统的发展，用户数量可能会增长到1000，而子类别和视频的数量可能会在10000。
问题是我们应该在每个请求访问数据库的地方继续当前的工作方式，还是应该考虑缓存数据？
我们正在使用IIS 6/7和Asp.net。
Answers:
首先，确保对代码进行分区，以便可以轻松切换数据提供者。我们在这里谈论接口隔离和其他SOLID原则。
接下来，您需要知道以下答案：
1）数据会经常更改吗？2）应用程序是否经常轮询REST服务以获取这些更新？3）该数据库是否用于其他目的？4）您知道当前的任何性能问题吗？5）您的应用程序是否更新了数据，这些更新是否需要在应用程序中反映出来？
有趣的是，通过使用数据库，您已经在技术上缓存了数据。这就是数据库的工作。为了使数据库在检索数据时尽可能快，进行了大量的研发工作。例如，它使用自己的内存缓存来存储常用数据。
因此，问问自己自己，通过交换缓存提供程序您希望获得什么？以及当前需要解决的限制是什么？
如果您目前没有遇到任何问题，我会简单地说“不，无需切换”。
这是一个很大的话题。当数据需要在地理位置上分布时，缓存往往表现得很好，但是在管理方面存在巨大的开销。
我正在做一个项目，当时我正在做完全相同的决策。
到目前为止，我的解决方案是仅使用数据库，并通过每个客户端的轮询请求对其进行大量处理。听起来很麻烦，但是（在测试中）可扩展性远远超出了我的需要，代码非常简单。
也就是说，我的代码使用了一种存储库模式，该模式从数据库代码中提取了主应用程序的数据提供程序。如果我想交换GemFire这样的缓存提供程序，则只需要执行很少的代码即可。
根据Thorbjørn的评论，确实没有足够的信息。
如果做错了，缓存可能会给您和您的用户带来很多麻烦。在使应用程序过于复杂之前，请确保您需要担心缓存。
因此，在没有信息表明您确实需要缓存时，请不要缓存。
[优化的一般规则：如果您需要问我是否应该做某事，答案是否定的] *
*在大多数答案是肯定的地方，这只是一个陈述，而不是一个问题。