Spring Data的MongoTemplate和MongoRepository有什么区别？

我需要编写一个应用程序，可以使用spring-data和mongodb进行复杂的查询。我一直从使用MongoRepository开始，但是在复杂的查询中苦苦寻找实例或真正理解语法。

我说的是这样的查询：

@Repository
public interface UserRepositoryInterface extends MongoRepository<User, String> {
    List<User> findByEmailOrLastName(String email, String lastName);
}

或使用基于JSON的查询，但由于语法不正确，因此尝试了多次尝试。即使在阅读了mongodb文档之后（由于语法错误，仍无法正常工作的示例）。

@Repository
public interface UserRepositoryInterface extends MongoRepository<User, String> {
    @Query("'$or':[{'firstName':{'$regex':?0,'$options':'i'}},{'lastName':{'$regex':?0,'$options':'i'}}]")
    List<User> findByEmailOrFirstnameOrLastnameLike(String searchText);
} 

阅读完所有文档后，似乎mongoTemplate文档要好得多MongoRepository。我指的是以下文档：

http://static.springsource.org/spring-data/data-mongodb/docs/current/reference/html/

您能告诉我使用什么更方便，更强大吗？mongoTemplate还是MongoRepository？两者都是成熟的，还是其中一个比另一个缺少更多的功能？

“方便”和“使用功能强大”在某种程度上是相互矛盾的目标。到目前为止，存储库比模板方便得多，但是后者当然可以为您提供对执行内容的更细粒度的控制。

由于存储库编程模型可用于多个Spring Data模块，因此您可以在Spring Data MongoDB 参考文档的常规部分中找到有关它的更多详细文档。

TL; DR

我们通常建议采用以下方法：

1. 从存储库摘要开始，仅使用查询派生机制或手动定义的查询声明简单查询。
2. 对于更复杂的查询，请向存储库添加手动实现的方法（如此处所述）。供实现使用MongoTemplate。

细节

对于您的示例，这看起来像这样：

1. 为您的自定义代码定义一个接口：

   interface CustomUserRepository {
   
     List<User> yourCustomMethod();
   }

2. 为此类添加一个实现，并遵循命名约定以确保我们可以找到该类。

   class UserRepositoryImpl implements CustomUserRepository {
   
     private final MongoOperations operations;
   
     @Autowired
     public UserRepositoryImpl(MongoOperations operations) {
   
       Assert.notNull(operations, "MongoOperations must not be null!");
       this.operations = operations;
     }
   
     public List<User> yourCustomMethod() {
       // custom implementation here
     }
   }

3. 现在，让您的基本存储库界面扩展自定义界面，基础结构将自动使用您的自定义实现：

   interface UserRepository extends CrudRepository<User, Long>, CustomUserRepository {
   
   }

这样，您基本上可以选择：易于声明的UserRepository所有内容都可以进入，而更好地手动实现的所有内容都可以进入CustomUserRepository。自定义选项在此处记录。

这个答案可能有点延迟，但是我建议避免使用整个存储库路径。您获得的具有重大实用价值的实现方法很少。为了使它起作用，您会遇到Java配置的废话，您可以花数天甚至数周的时间而无需在文档中提供太多帮助。

相反，请选择 MongoTemplate条路线，并创建自己的数据访问层，这使您摆脱了Spring程序员面临的配置噩梦。MongoTemplate对于那些能够灵活地构建自己的类和交互的工程师来说，它确实是一个救星，因为它具有很大的灵活性。结构可以是这样的：

1. 创建一个 MongoClientFactory将在应用程序级别运行类，并为您提供一个MongoClient对象。您可以将其实现为Singleton或使用Enum Singleton（这是线程安全的）
2. 创建一个数据访问基类，您可以从中继承每个域对象的数据访问对象。基类可以实现一种用于创建MongoTemplate对象的方法，您可以将此类的特定方法用于所有数据库访问
3. 每个域对象的每个数据访问类都可以实现基本方法，也可以在基类中实现它们
4. 然后，Controller方法可以根据需要调用数据访问类中的方法。

FWIW，关于多线程环境中的更新：

• MongoTemplate提供“原子”外的开箱操作 updateFirst，updateMulti，findAndModify，upsert...，让你可以在一个单一的操作修改文档。Update这些方法使用的对象还允许您仅定位相关字段。
• MongoRepository只给你基本的CRUD操作 find，insert，save，delete，其作品包含的POJO 的所有字段。这迫使您要么分几个步骤find来更新文档（1. 要更新的文档，2.修改返回的POJO中的相关字段，然后3.修改save），或者使用手动定义自己的更新查询@Query。

在多线程环境中，例如带有多个REST端点的Java后端，为了减少两个并发更新覆盖彼此的更改的机会，单方法更新是必经之路。

示例：给定这样的文档：{ _id: "ID1", field1: "a string", field2: 10.0 }并且两个不同的线程同时更新它...

有了MongoTemplate它看起来像这样：

THREAD_001                                                      THREAD_002
|                                                               |
|update(query("ID1"), Update().set("field1", "another string")) |update(query("ID1"), Update().inc("field2", 5))
|                                                               |
|                                                               |

文档的最终状态始终是{ _id: "ID1", field1: "another string", field2: 15.0 }因为每个线程仅访问DB一次，并且仅更改了指定字段。

与此相同的情况MongoRepository如下所示：

THREAD_001                                                      THREAD_002
|                                                               |
|pojo = findById("ID1")                                         |pojo = findById("ID1")
|pojo.setField1("another string") /* field2 still 10.0 */       |pojo.setField2(pojo.getField2()+5) /* field1 still "a string" */
|save(pojo)                                                     |save(pojo)
|                                                               |
|                                                               |

最终文档是{ _id: "ID1", field1: "another string", field2: 10.0 }或{ _id: "ID1", field1: "a string", field2: 15.0 }取决于哪个save操作最后命中数据库。
（注意：即使我们按照注释中的建议使用Spring Data的@Version注释，也不会有太大变化：其中一个save操作将抛出OptimisticLockingFailureException，最终文档仍将是上述之一，并且仅更新一个字段而不是两个字段。 ）

因此，我想这MongoTemplate是一个更好的选择，除非您有一个非常详细的POJO模型或MongoRepository出于某种原因需要自定义查询功能。