在这种情况下可以使用任何设计模式吗？

Question

我们有一个长期处于积极开发/维护状态（如十年）的系统（Java Web应用程序）。

我们正在研究的是为Web应用程序实现一个RESTful API。这个使用Jersey的Web应用程序将是一个单独的项目，意图是它应该能够与主应用程序一起运行或部署在云中。由于我们的应用程序的性质和年龄，我们不得不在数据库（postgres）之上实现一个（稍微）全面的缓存层，以帮助减少负载。无论如何，对于RESTful API，这个想法是GET请求将首先进入缓存而不是数据库来保持数据库的加载。

缓存将以一种方式填充，以帮助确保注册的API用户将需要的大部分内容都应该放在那里。

如果存在高速缓存未命中，则应从数据库中检索所需数据（还要输入进程中的高速缓存）。

显然，我的代码中的RESTful端点方法应该保持透明。我们想出了创建'Broker'来处理与数据库和缓存的通信的想法。 REST层将简单地通过ID（如果想要检索）或填充的Java对象（如果希望插入/更新）并且代理将负责检索/更新/无效等。

还有问题的可扩展性。首先，API将与其他服务器共存，因此访问数据库不会成为问题，但是如果我们部署到云中，我们将需要一个不同的代理实现来与系统进行通信（即数据库）以不同的方式（可能通过使用内部API）。

我已经对如何实现这一点有了一个粗略的想法，但它让我感到可能是一个适合的模式可能存在的问题。如果我可以按照既定模式而不是提出自己的解决方案，那可能是更好的选择。有任何想法吗？

Answer 1

没有模式。只需隐藏接口后面的初始数据库服务，围绕其预期行为构建测试，然后切换使用缓存层的实现。我想依赖注入将是最好的帮助你做到这一点？

Answer 2

听起来像装饰模式将满足你的需要：http://en.wikipedia.org/wiki/Decorator_pattern。

您可以创建一个DAO接口进行数据访问，是这样的：

Value get(long id); 

，首次创建直接DB实现，然后创建一个缓存实现其调用底层DAO例如，在这种情况下，它应该是DB实现。

缓存实现将努力让自身的被管理高速缓存，并从垫层DAO如果失败值。

因此，您的旧应用程序或REST都只能看到DAO接口，而不知道任何实现细节，并且将来可以自由更改实现。

Answer 3

的Ehcache便是这样，它调用SelfPopulatingCache缓存的实现。

请求的是缓存，而不是数据库。然后，如果有缓存未命中，Ehcache将以您的名义调用数据库（或您拥有的任何外部数据源）。

你只需要实现CacheEntryFactory其中有一个方法：

Object createEntry(Object key) throws Exception; 

所以顾名思义，实现了Ehcache这个概念有一个相当标准的工厂模式...

Answer 4

最好的设计透明缓存HTTP请求的模式是使用anHTTPcache。