Tavaszi adatok összeállítható adattárak

1. Bemutatkozás

Valós rendszer vagy folyamat modellezésénél a tartományvezérelt tervezésű (DDD) stílusú tárak jó választás. Éppen erre a célra használhatjuk a Spring Data JPA-t adatelérési absztrakciós rétegünkként.

Ha még nem ismeri ezt a koncepciót, akkor nézze meg ezt a bevezető oktatóanyagot, amely segít felgyorsulni.

Ebben az oktatóanyagban az egyedi és az összeállítható tárak létrehozásának koncepciójára fogunk összpontosítani, amelyek kisebb töredékek, ún. Töredékek felhasználásával jönnek létre.

2. Maven-függőségek

Az összeállítható tárak létrehozásának lehetősége az 5. tavasztól kezdődően elérhető.

Adjuk hozzá a Spring Data JPA szükséges függőségét:

 org.springframework.data spring-data-jpa 2.2.2.KÖZLEMÉNY 

Be kell állítanunk egy adatforrást is, hogy az adatelérési rétegünk működhessen. Célszerű létrehozni egy memóriában lévő adatbázist, például a H2-t fejlesztés és gyors tesztelés céljából.

3. Háttér

3.1. Hibernálás JPA-megvalósításként

A Spring Data JPA alapértelmezés szerint a hibernált módot használja JPA megvalósításként. Könnyen összekeverhetjük a másikat, vagy összehasonlíthatjuk őket, de különböző célokat szolgálnak.

A Spring Data JPA az adatelérési absztrakciós réteg, amely alatt bármilyen megvalósítást felhasználhatunk. Kikapcsolhatjuk például a Hibernate funkciót az EclipseLink javára.

3.2. Alapértelmezett adattárak

Sok esetben nem kellene magunknak írnunk semmilyen kérdést.

Ehelyett csak olyan interfészeket kell létrehoznunk, amelyek viszont kiterjesztik az általános Spring adattár interfészeket:

nyilvános felület A LocationRepository kiterjeszti a JpaRepository {}

És ez önmagában lehetővé tenné számunkra, hogy közös műveleteket végezzünk - CRUD, lapozás és rendezés - a Elhelyezkedés objektum, amelynek elsődleges típusa van Hosszú.

Ezenkívül a Spring Data JPA egy lekérdezés-készítő mechanizmussal rendelkezik, amely lehetővé teszi a lekérdezések létrehozását a nevünkben a metódusnév konvenciók használatával:

nyilvános felület StoreRepository kiterjeszti a JpaRepository {List findStoreByLocationId (Long locationId); }

3.3. Egyéni tárak

Ha szükséges, megtehetjük gazdagítsa modelltárunkat egy töredék interfész megírásával és a kívánt funkcionalitás megvalósításával. Ez azután beadható a saját JPA-tárunkba.

Például itt gazdagítjuk a sajátunkat ItemTypeRepository egy fragment töredék kibővítésével:

nyilvános felület Az ItemTypeRepository kiterjeszti a JpaRepository, a CustomItemTypeRepository {}

Itt CustomItemTypeRepository egy másik felület:

nyilvános felület CustomItemTypeRepository {void deleteCustomById (ItemType entitás); }

Megvalósítása bármilyen tárház lehet, nemcsak a JPA:

public class CustomItemTypeRepositoryImpl implementálja a CustomItemTypeRepository {@Autowired private EntityManager entitásManager; @Override public void deleteCustomById (ItemType itemType) {entitásManager.remove (itemType); }}

Csak meg kell győződnünk arról, hogy a postfix van-e benne Impl. Egyéni postfixet azonban beállíthatunk a következő XML-konfiguráció használatával:

vagy a következő kommentár használatával:

@EnableJpaRepositories (basePackages = "com.baeldung.repository", repositoryImplementationPostfix = "CustomImpl")

4. Tárak összeállítása több töredék használatával

Néhány évvel ezelőtti adatokig csak egyetlen egyedi megvalósítással tudtuk kibővíteni a tárház felületeit. Ez egy olyan korlátozás volt, amely miatt az összes kapcsolódó funkciót egyetlen objektumba kell vonnunk.

Mondanom sem kell, hogy a komplex tartománymodellekkel rendelkező nagyobb projekteknél ez duzzadt osztályokhoz vezet.

Most az 5. tavasszal lehetőségünk van arra, hogy gazdagítsa a JPA adattárunkat több töredéktárral. Megint megmarad az a követelmény, hogy ezek a töredékek interfész-megvalósítási párokként legyenek.

Ennek bemutatásához hozzunk létre két töredéket:

nyilvános felület CustomItemTypeRepository {void deleteCustom (ItemType entitás); void findThenDelete (Hosszú id); } nyilvános felület CustomItemRepository {Item findItemById (Long id); void deleteCustom (Elem entitás); void findThenDelete (Hosszú id); }

Természetesen meg kell írnunk a megvalósításukat. De ahelyett, hogy ezeket az egyedi adattárakat - a kapcsolódó funkcionalitásokkal - saját JPA-tárházakba csatlakoztatnánk, kibővíthetjük egyetlen JPA-adattár funkcionalitását:

nyilvános felület Az ItemTypeRepository kiterjeszti a JpaRepository, a CustomItemTypeRepository, a CustomItemRepository {}

Most minden összekapcsolt funkcióval rendelkeznénk egyetlen tárban.

5. A kétértelműség kezelése

Mivel több adattárból örököltünk, problémáink lehetnek, hogy kitaláljuk, melyik megvalósításunkat használják összeütközés esetén. Például a példánkban mindkét töredéktároló rendelkezik módszerrel, findThenDelete (), ugyanazzal az aláírással.

Ebben a forgatókönyvben az interfészek deklarálásának sorrendjét használják a kétértelműség feloldására. Következésképpen esetünkben a módszer belül CustomItemTypeRepository fogják használni, mivel először deklarálták.

Ezt a teszteset segítségével tesztelhetjük:

@Test public void givenItemAndItemTypeWhenDeleteThenItemTypeDeleted () {Opcionális itemType = composRepository.findById (1L); assertTrue (itemType.isPresent ()); Elemelem = composRRepository.findItemById (2L); assertNotNull (elem); composRepository.findThenDelete (1L); Opcionális sameItemType = composRepository.findById (1L); assertFalse (sameItemType.isPresent ()); Elem sameItem = sablonRepository.findItemById (2L); assertNotNull (sameItem); }

6. Következtetés

Ebben a cikkben megvizsgáltuk a Spring Data JPA adattárak különböző módjait. Láttuk, hogy a Spring megkönnyíti az adatbázis-műveletek végrehajtását a domainobjektumainkon anélkül, hogy sok kódot vagy akár SQL-kérdést írna.

Ez a támogatás jelentősen testreszabható az összeállítható tárak használatával.

A cikkből származó kódrészletek Maven-projektként érhetők el itt, a GitHubon.


$config[zx-auto] not found$config[zx-overlay] not found