В чем разница между MongoTemplate Spring Data и 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. Параметры настройки задокументированы здесь .

FWIW, относительно обновлений в многопоточной среде:

• MongoTemplate < / a> предоставляет нестандартные атомарные операции updateFirst, updateMulti, findAndModify, _5 _..., которые позволяют изменять документ за одну операцию. Объект Update, используемый этими методами, также позволяет настраивать таргетинг только на соответствующие поля.
• MongoRepository < / a> предоставляет вам только базовые операции CRUD find, insert, save, delete, которые работают с объектами POJO, содержащими все поля. Это вынуждает вас либо обновить документы в несколько этапов (1. find документ, который нужно обновить, 2. изменить соответствующие поля из возвращенного POJO, а затем 3. save это), либо определить свои собственные запросы на обновление вручную с помощью @Query.

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

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 операция попадает в БД последней.
_{(ПРИМЕЧАНИЕ: даже если мы использовали} @Version аннотация Spring Data, как предложено в комментариях, мало что изменится: одна из save операции будут выдавать OptimisticLockingFailureException, и окончательный документ все равно будет одним из перечисленных выше, с обновлением только одного поля вместо обоих.)

Поэтому я бы сказал, что MongoTemplate - лучший вариант, если у вас нет очень сложной модели POJO или вам по какой-то причине не нужны возможности пользовательских запросов MongoRepository.

Этот ответ может быть немного запоздалым, но я бы рекомендовал избегать всего пути к репозиторию. Вы получаете очень мало реализованных методов, имеющих большую практическую ценность. Чтобы заставить его работать, вы сталкиваетесь с ерундой конфигурации Java, на которую вы можете потратить дни и недели без особой помощи в документации.

Вместо этого выберите путь MongoTemplate и создайте свой собственный уровень доступа к данным, который избавит вас от кошмаров конфигурации, с которыми сталкиваются программисты Spring. MongoTemplate - действительно спаситель для инженеров, которым удобно создавать собственные классы и взаимодействия, поскольку существует большая гибкость. Структура может быть примерно такой:

1. Создайте MongoClientFactory класс, который будет работать на уровне приложения и даст вам MongoClient объект. Вы можете реализовать это как Singleton или с помощью Enum Singleton (это потокобезопасно)
2. Создайте базовый класс доступа к данным, от которого вы можете наследовать объект доступа к данным для каждого объекта домена). Базовый класс может реализовать метод для создания объекта MongoTemplate, который методы вашего класса могут использовать для всех обращений к БД.
3. Каждый класс доступа к данным для каждого объекта домена может реализовывать базовые методы, или вы можете реализовать их в базовом классе.
4. Затем методы контроллера могут при необходимости вызывать методы в классах доступа к данным.