В чем разница между MongoTemplate Spring Data и MongoRepository?

Question 1

Мне нужно написать приложение, с помощью которого я могу выполнять сложные запросы с использованием 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? Оба они одинаковы зрелые или у одного из них не хватает функций, чем у другого?

Question 2

«Удобный» и «мощный в использовании» в некоторой степени противоречат целям. Репозитории намного удобнее, чем шаблоны, но последние, конечно, дают вам более точный контроль над тем, что выполнять.

Поскольку модель программирования репозитория доступна для нескольких модулей Spring Data, вы найдете более подробную документацию по ней в общем разделе справочной документации Spring Data MongoDB .

TL; DR

Обычно мы рекомендуем следующий подход:

Начните с аннотации репозитория и просто объявляйте простые запросы, используя механизм деривации запросов или задаваемые вручную запросы.
Для более сложных запросов добавьте в репозиторий вручную реализованные методы (как описано здесь). Для реализации используйте MongoTemplate.

Детали

В вашем примере это будет выглядеть примерно так:

Определите интерфейс для вашего пользовательского кода:
```
interface CustomUserRepository {

  List<User> yourCustomMethod();
}
```

Добавьте реализацию для этого класса и следуйте соглашению об именах, чтобы убедиться, что мы можем найти класс.

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
  }
}

Теперь позвольте вашему базовому интерфейсу репозитория расширить настраиваемый интерфейс, и инфраструктура автоматически будет использовать вашу настраиваемую реализацию:
```
interface UserRepository extends CrudRepository<User, Long>, CustomUserRepository {

}
```

Таким образом, вы, по сути, получаете выбор: все, что просто объявить, входит в состав UserRepository, все, что лучше реализовать вручную, входит CustomUserRepository. Параметры настройки описаны здесь .

Question 3

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

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

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

Question 4

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

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

В многопоточной среде, такой как, например, серверная часть Java с несколькими конечными точками REST, обновление с использованием одного метода - это путь, чтобы уменьшить вероятность того, что два одновременных обновления перезапишут изменения друг друга.

Пример: учитывая такой документ: { _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 }поскольку каждый поток обращается к БД только один раз, и только указанное поле изменяется.

В то время как тот же сценарий 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по какой-то причине не нужны возможности настраиваемых запросов .