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

Question

Potrzebuję napisać aplikację, za pomocą której mogę wykonywać złożone zapytania za pomocą wiosennych danych i mongodb. Zaczynałem od używania MongoRepository, ale zmagałem się ze złożonymi zapytaniami, aby znaleźć przykłady lub faktycznie zrozumieć składnię.

mówię zapytaniami tak:

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

lub wykorzystanie JSON zapytań opartych który Próbowałem metodą prób i błędów, bo nie dostać prawo składni. Nawet po przeczytaniu dokumentacji mongodb (niepracują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 jest znacznie lepiej mongoTemplate udokumentowane następnie MongoRepository. Chodzi mi o następującej dokumentacji:

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

Czy możesz mi powiedzieć, co jest bardziej wygodne i wydajne w użyciu? mongoTemplate lub MongoRepository? Czy oba są takie same, czy jedno z nich nie ma więcej cech niż drugie?

Answer 1

"Wygodne" i "użyteczne w użyciu" w pewnym stopniu są sprzeczne z celami. Repozytoria są znacznie wygodniejsze niż szablony, ale te ostatnie dają oczywiście większą kontrolę nad tym, co należy wykonać.

Ponieważ model programowania repozytoriów jest dostępny dla wielu modułów danych sprężynowych, można znaleźć dokładniejszą dokumentację tego w sekcji ogólnej danych sprężynowych MongoDB reference docs.

TL; DR

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

1. Start z repozytorium abstrakcyjne i po prostu zadeklarować prostych zapytań za pomocą mechanizmu uzyskiwania zapytanie lub ręcznie zdefiniowanych zapytań.
2. W przypadku bardziej złożonych zapytań dodaj ręcznie zaimplementowane metody do repozytorium (zgodnie z dokumentacją tutaj). Do wdrożenia użyj MongoTemplate.

Szczegóły

Dla przykładu to będzie wyglądać mniej więcej tak:

1. zdefiniować interfejs dla kodu niestandardowego:

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

2. Dodaj implementację dla w tej klasie i postępuj zgodnie z konwencją nazewnictwa, aby upewnić się, że możemy znajdź 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 niech interfejs repozytorium baza przedłużyć zwyczaj jedna i ta infrastruktura będzie automatycznie korzystać z wdrożenia niestandardowe:

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

W ten sposób można w zasadzie uzyskać wyboru: wszystko, co tylko proste aby zadeklarować, przechodzi w UserRepository, wszystko, co jest lepiej zaimplementowane ręcznie, przechodzi w CustomUserRepository. Opcje dostosowywania są udokumentowane here.

Answer 2

Ta odpowiedź może być nieco opóźniona, ale zaleca się unikanie całej trasy repozytorium. Otrzymujesz bardzo mało wdrożonych metod o dowolnej wartości praktycznej. Aby to zadziałało, wpadasz w bzdury konfiguracji Java, które możesz spędzać dniami i tygodniami bez dużej pomocy w dokumentacji.

Zamiast tego należy udać się z trasą MongoTemplate i utworzyć własną warstwę dostępu do danych, która uwalnia od koszmarów konfiguracyjnych, przed którymi stają programiści Spring. MongoTemplate jest naprawdę zbawicielem dla inżynierów, którzy czują się wygodnie w projektowaniu własnych klas i interakcji, ponieważ jest w nich dużo elastyczności. Struktura może być coś takiego:

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