使用搜索服务器服务层vs数据库层来查找实体

如果您同时设置了搜索API（使用Elasticsearch）和存储库层（Spring JDBC），那么无论查询有多么微不足道，您都会使用搜索API吗？它比版本库更灵活，但速度稍慢。例如：您是否会使用搜索api按某些创作者的名字获取所有汽车？使用搜索服务器服务层vs数据库层来查找实体

2013-04-01 LuckyLuke

好像你有一个仓库和ES坐在旁边的海誓山盟一些重叠的查询功能

存储库的强度（如果我们谈论一个DDD库即是）是提供一个接口对于客户端而言，不必知道您是如何在后端实际执行查询的。

说回购实现： getById(id) getByName(name) getByExample(JsonExample) getByFullText(text)

我会完全恢复健康的使用您的主数据存储来实现getById（也许getByName）。（mysql，mongoDB，couchbase或任何你用来提供ES的东西）

同时getByFullText(text)肯定会被ES和getByExample(JsonExample)实现。

问题是，通过将实现置于存储库抽象的后面，应用程序的其余部分无法/不应该不在乎你如何实际实现它。

对于你来说，只要用自然的感觉（get all cars by some creators name可以同时适用于ES和你的主要数据存储）如果你的路上有真正的（性能或其他）切换原因，它只是一个一行代码可能在您的存储库实现中。

BTW：具有多个不同的数据存储服务您的查询的概念被称为：Polyglot Persistance.

2013-04-01 15:54:34

啊，对这样你就不会创建一个服务层“搜索服务”，而是将其移动存储库抽象的背后？ – LuckyLuke

但是，如果是这种情况，我有一些如何更改我的代码的问题。现在我有一些类，如SearchContext和SearchResponse，我是否必须更改这些名称以保持搜索服务器的抽象？或者我还可以返回这些吗？基本上，保留一些搜索类/术语是不好的，即使它是通过存储库处理的。 – LuckyLuke

对于给定的示例：'通过创建者名称获取所有汽车'，我确实在存储库抽象背后有搜索实现。这并不是说没有用于单独的搜索服务。（例如：对于真正的搜索特定的东西，比如打字/提示，突出显示，刻面等）。因此，请不要把我的图片作为从不想单独搜索的服务。这取决于什么是有道理的。 –

回答