Es fällt mir schwer zu entscheiden, ob ich bei einem neuen Projekt bei Hibernate bleiben oder mich mit JPA und der neuen Spring Data-Implementierung anfreunden soll.
Ist das Spring Data-Framework für große Projekte oder kleine Projekte mit bescheidenen Abfrageanforderungen gedacht?
Während ich sicherlich den Vorteil in der Codereduzierung sehe, indem ich die @Query
Anmerkung, was tun Sie bei dynamischen Abfragen? Was ist, wenn Sie eine recht komplexe save()-Methode implementieren möchten?
Die Dokumentation besagt, dass Sie eine benutzerdefinierte Schnittstelle und Implementierung erstellen sollen, die Ihr Haupt-Repository implementiert, aber was ist, wenn Sie auf Supermethoden im Crud-Repository selbst zugreifen müssen? Das Crud-Repository implementiert das benutzerdefinierte – nicht umgekehrt. Es scheint ein seltsames Design zu sein.
Ich bin sehr unsicher, ob dieses Framework den Herausforderungen komplexer und großer Anwendungen gewachsen ist. Ich bin nie auf viele Probleme mit Hibernate gestoßen, und ich überlege, lieber bei der guten alten Zuverlässigkeit zu bleiben, als mich für Spring Data JPA zu entscheiden.
Was soll ich machen? Auf welche unvorhergesehenen Komplikationen und Kosten werde ich stoßen, wenn ich mich für Spring Data JPA entscheide?
So, spring-data
macht etwas zusätzliche Magie, die bei komplexen Abfragen hilft. Es ist zunächst seltsam und Sie überspringen es in der Dokumentation komplett, aber es ist wirklich mächtig und nützlich.
Es geht darum, eine benutzerdefinierte zu erstellen Repository
und ein benutzerdefiniertes `RepositoryImpl’ und Spring mitteilen, wo es zu finden ist. Hier ist ein Beispiel:
Konfigurationsklasse – zeigen Sie auf Ihre noch benötigte XML-Konfiguration mit Anmerkung, die auf Ihr Repositories-Paket zeigt (es sucht nach *Impl
Klassen jetzt automatisch):
@Configuration
@EnableJpaRepositories(basePackages = {"com.examples.repositories"})
@EnableTransactionManagement
public class MyConfiguration {
}
jpa-repositories.xml – erzählen Spring
wo Sie Ihre Repositories finden. Sagen Sie auch Spring
um nach benutzerdefinierten Repositories mit dem zu suchen CustomImpl
Dateiname:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:jpa="http://www.springframework.org/schema/data/jpa"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:util="http://www.springframework.org/schema/util"
xsi:schemaLocation="http://www.springframework.org/schema/data/mongo http://www.springframework.org/schema/data/jpa/spring-jpa.xsd
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util.xsd">
<jpa:repositories base-package="com.example.repositories" repository-impl-postfix="CustomImpl" />
</beans>
MyObjectRepository
– Hier können Sie kommentierte und nicht kommentierte Abfragemethoden einfügen. Beachten Sie, wie diese Repository-Schnittstelle die erweitert Custom
eines:
@Transactional
public interface MyObjectRepository extends JpaRepository<MyObject, Integer>, MyObjectRepositoryCustom {
List<MyObject> findByName(String name);
@Query("select * from my_object where name = ?0 or middle_name = ?0")
List<MyObject> findByFirstNameOrMiddleName(String name);
}
MyObjectRepositoryCustom
– Repository-Methoden, die komplexer sind und nicht mit einer einfachen Abfrage oder einer Annotation behandelt werden können:
public interface MyObjectRepositoryCustom {
List<MyObject> findByNameWithWeirdOrdering(String name);
}
MyObjectRepositoryCustomImpl
– wo Sie diese Methoden tatsächlich mit einem Autowired implementieren EntityManager
:
public class MyObjectRepositoryCustomImpl implements MyObjectRepositoryCustom {
@Autowired
private EntityManager entityManager;
public final List<MyObject> findByNameWithWeirdOrdering(String name) {
Query query = query(where("name").is(name));
query.sort().on("whatever", Order.ASC);
return entityManager.find(query, MyObject.class);
}
}
Erstaunlicherweise kommt das alles zusammen und Methoden von beiden Schnittstellen (und der CRUD-Schnittstelle, die Sie implementieren) werden alle angezeigt, wenn Sie dies tun:
myObjectRepository.
Du wirst sehen:
myObjectRepository.save()
myObjectRepository.findAll()
myObjectRepository.findByName()
myObjectRepository.findByFirstNameOrMiddleName()
myObjectRepository.findByNameWithWeirdOrdering()
Es funktioniert wirklich. Und Sie erhalten eine Schnittstelle für Abfragen. spring-data
ist wirklich bereit für eine große Anwendung. Und je mehr Abfragen Sie in einfache oder Anmerkungen schieben können, desto besser sind Sie dran.
All dies ist dokumentiert in der Spring Data Jpa-Site.
Viel Glück.
Ich habe Spring Data JPA in kleinen und großen Projekten mit einfachen Abfrageanforderungen verwendet. Der Hauptvorteil besteht darin, dass Sie die nicht einmal verwenden müssen @Query
Anmerkung. In Spring Data gibt es nichts, was Sie daran hindert, es in großen und aktuellen Projekten zu verwenden QueryDSL
Unterstützung könnte Ihnen helfen. Dies ist ein Beispiel vom Benutzen AbfrageDSL auf Hibernate abzielen.
Wenn Sie komplexe Abfragen voraussehen und sich mit der Verwendung von Hibernate-Objekten ohne JPA wohlfühlen, denke ich, dass eine alternative Kombination darin bestehen könnte, die einfachen Spring Data zu haben Repository
s neben komplexen Hibernate-basierten mit den spezifischen Methoden, die Sie möglicherweise benötigen. Es könnte weniger umständlich sein, eine Hibernate-Implementierung in die Spring Data JPA-Struktur zu verdrehen.
Spring JPA bietet Ihnen viel Abstraktion vom Schreiben von SQL und sogar etwas HQL mit der Deklaration von Abfragemethoden. Spring JPA glänzt mit seiner Abfragegenerierung, aber wenn Sie eine reine Hibernate-Lösung wünschen, können Sie diese nach Bedarf anpassen, da Spring JPA immer noch auf Hibernate basiert. Überprüfen Sie die Dokumente http://static.springsource.org/spring-data/data-jpa/docs/current/reference/html Für mehr Information.
Soweit ich weiß, macht es kaum einen Unterschied. Gehen Sie mit dem, mit dem Sie sich wohler fühlen. Warum die Debatte?
– Duffymo
8. Oktober 2012 um 23:26 Uhr
Ich fühle mich offensichtlich viel wohler mit Hibernate, aber wenn ich die gleichen Dinge tun und produktiver sein kann, würde ich lieber die neueren Ansätze übernehmen. Wenn Hibernate jedoch noch leistungsfähiger ist und ich auf viel weniger Probleme stoße, dann würde ich gerne etwas darüber wissen.
– egervari
8. Oktober 2012 um 23:27 Uhr
JPA ist eine Verallgemeinerung von ORM, die Hibernate als eine von vielen Implementierungen verwendet. Welche Befugnisse schreiben Sie dem einen über den anderen zu? JPA ist ein Standard, aber ich sehe kaum einen Unterschied zwischen den beiden. Im Interesse einer vollständigen Offenlegung werde ich sagen, dass mir beides egal ist. Beide generieren SQL für Sie. Ich schreibe es lieber selbst. ORM ist nicht für jedes Problem und jeden Benutzer geeignet.
– Duffymo
8. Oktober 2012 um 23:29 Uhr
Ich stimme zu. Wenn es nur um JPA oder Hibernate geht, würde ich jedes Mal Hibernate wählen. Ich mag die JPA-Implementierung ehrlich gesagt nicht so sehr. Die IDE-Unterstützung in IDEA ist eigentlich immer noch ziemlich schlecht, und es wird sich beschweren, wenn die Zuordnungen nicht korrekt sind, wenn die Anwendung startet, anstatt die Komponententests laufen zu lassen. Es gibt viele andere Nitpicks, die ich mit JPA habe. Eigentlich mag ich die alten XML-Mapping-Dateien von Hibernate. Es hat den Vorteil, dass meine Objekte auch viel weniger überladen aussehen. Spring Data JPA bietet viele neue Funktionen, daher habe ich mich schließlich gefragt, ob sich der Wechsel lohnt.
– egervari
9. Oktober 2012 um 0:57 Uhr
“Spring Data” ist keine Implementierung von JPA oder irgendetwas. Es nimmt einfach eine vorhandene JPA-Implementierung und vereinfacht, was Sie ihr bereitstellen. Die JPA-Implementierung erledigt immer noch die ganze Arbeit im Verborgenen
– Neil Stockton
26. Januar 2016 um 18:36 Uhr