Jaka jest różnica między MongoTemplate Spring Data a MongoRepository?

Muszę napisać aplikację, w której będę mógł wykonywać złożone zapytania przy użyciu spring-data i mongodb. Zaczynałem od korzystania z MongoRepository, ale zmagałem się ze złożonymi zapytaniami, aby znaleźć przykłady lub faktycznie zrozumieć składnię.

Mówię o zapytaniach takich jak to:

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

lub użycie zapytań opartych na JSON, które próbowałem metodą prób i błędów, ponieważ nie rozumiem właściwej składni. Nawet po przeczytaniu dokumentacji mongodb (niedziałający przykład z powodu złej składni).

@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);
} 

Po przeczytaniu całej dokumentacji wydaje się, że mongoTemplatejest ona wtedy znacznie lepiej udokumentowana MongoRepository. Mam na myśli następującą dokumentację:

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

Czy możesz mi powiedzieć, co jest wygodniejsze i wydajniejsze w użyciu? mongoTemplateczy MongoRepository? Czy oboje są tak samo dojrzali, czy jednemu z nich brakuje więcej funkcji niż drugiemu?

„Wygodne” i „wydajne w użyciu” są w pewnym stopniu sprzeczne z celami. Repozytoria są zdecydowanie wygodniejsze niż szablony, ale te ostatnie dają oczywiście bardziej szczegółową kontrolę nad tym, co należy wykonać.

Ponieważ model programowania repozytorium jest dostępny dla wielu modułów Spring Data, bardziej szczegółową dokumentację można znaleźć w sekcji ogólnej dokumentacji źródłowej Spring Data MongoDB .

TL; DR

Ogólnie zalecamy następujące podejście:

1. Zacznij od streszczenia repozytorium i po prostu zadeklaruj proste zapytania przy użyciu mechanizmu wyprowadzania zapytań lub zapytań zdefiniowanych ręcznie.
2. W przypadku bardziej złożonych zapytań dodaj ręcznie implementowane metody do repozytorium (zgodnie z dokumentacją tutaj). Do realizacji użyj MongoTemplate.

Detale

Na przykład wyglądałoby to mniej więcej tak:

1. Zdefiniuj interfejs dla swojego kodu niestandardowego:

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

2. Dodaj implementację dla tej klasy i postępuj zgodnie z konwencją nazewnictwa, aby upewnić się, że możemy znaleźć klasę.

   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. Teraz pozwól, aby Twój podstawowy interfejs repozytorium rozszerzył niestandardowy, a infrastruktura automatycznie użyje Twojej niestandardowej implementacji:

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

W ten sposób zasadniczo masz wybór: wszystko, co jest łatwe do zadeklarowania, wchodzi w skład UserRepository, wszystko, co lepiej zaimplementowano ręcznie, wchodzi do CustomUserRepository. Opcje dostosowywania są udokumentowane tutaj .

Ta odpowiedź może być nieco opóźniona, ale radziłbym omijać całą trasę repozytorium. Otrzymujesz bardzo mało wdrożonych metod o dużej wartości praktycznej. Aby to zadziałało, napotykasz bzdury dotyczące konfiguracji Javy, nad którymi możesz spędzać dni i tygodnie bez większej pomocy w dokumentacji.

Zamiast tego idź z MongoTemplatetrasą i utwórz własną warstwę dostępu do danych, która uwolni Cię od koszmarów konfiguracyjnych, z którymi borykają się programiści Spring. MongoTemplatejest naprawdę zbawieniem dla inżynierów, którzy czują się komfortowo przy tworzeniu własnych klas i interakcji, ponieważ zapewnia dużą elastyczność. Struktura może wyglądać mniej więcej tak:

1. Utwórz MongoClientFactoryklasę, która będzie działać na poziomie aplikacji i da ci MongoClientobiekt. Możesz zaimplementować to jako Singleton lub używając Enum Singleton (jest to bezpieczne wątkowo)
2. Utwórz klasę bazową dostępu do danych, z której możesz dziedziczyć obiekt dostępu do danych dla każdego obiektu domeny). Klasa bazowa może implementować metodę tworzenia obiektu MongoTemplate, którego metody klasy mogą używać dla wszystkich dostępów do bazy danych
3. Każda klasa dostępu do danych dla każdego obiektu domeny może implementować podstawowe metody lub można je zaimplementować w klasie bazowej
4. Metody kontrolera mogą następnie w razie potrzeby wywoływać metody w klasach dostępu do danych.

FWIW, dotyczące aktualizacji w środowisku wielowątkowym:

• MongoTemplatezapewnia „atomowy” out-of-the-box operacje updateFirst , updateMulti, findAndModify, upsert..., które pozwalają modyfikować dokument w jednej operacji. UpdateObiekt używany przez tych metod również pozwala kierować tylko odpowiednie pola .
• MongoRepositorytylko daje podstawowe operacje CRUD find , insert, save, delete, które pracują z POJOs zawierających wszystkie pola . Wymusza to albo aktualizację dokumentów w kilku krokach (1. finddokument do aktualizacji, 2. modyfikacja odpowiednich pól ze zwróconego POJO, a następnie 3. saveto), albo ręczne zdefiniowanie własnych zapytań aktualizacyjnych @Query.

W środowisku wielowątkowym, takim jak np. Zaplecze Java z kilkoma punktami końcowymi REST, najlepszym rozwiązaniem są aktualizacje przy użyciu jednej metody, aby zmniejszyć prawdopodobieństwo, że dwie równoległe aktualizacje nadpisują nawzajem zmiany.

Przykład: mając taki dokument: { _id: "ID1", field1: "a string", field2: 10.0 }i dwa różne wątki jednocześnie go aktualizujące ...

Dzięki MongoTemplatetemu wyglądałoby to mniej więcej tak:

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

a ostatecznym stanem dokumentu jest zawsze, { _id: "ID1", field1: "another string", field2: 15.0 }ponieważ każdy wątek uzyskuje dostęp do bazy danych tylko raz i tylko określone pole jest zmieniane.

Podczas gdy ten sam scenariusz z MongoRepositorywyglądałby tak:

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

a końcowy dokument jest albo { _id: "ID1", field1: "another string", field2: 10.0 }czy { _id: "ID1", field1: "a string", field2: 15.0 }w zależności od saveoperacji uderza DB ostatni.
(UWAGA: Nawet gdybyśmy użyli adnotacji Spring Data,@Version jak sugerowano w komentarzach, niewiele by się zmieniło: jedna z saveoperacji wyrzuciłaby OptimisticLockingFailureException, a dokument końcowy byłby nadal jednym z powyższych, z zaktualizowanym tylko jednym polem zamiast obu. )

Więc powiedziałbym, że MongoTemplatejest to lepsza opcja , chyba że masz bardzo rozbudowany model POJO lub z MongoRepositoryjakiegoś powodu potrzebujesz niestandardowych możliwości zapytań .