streamalism.org

Gyakran a tár és a DAO implementációit felcserélhetőnek tartják, különösen az adatközpontú alkalmazásokban. Ez zavart kelt a különbségeikben.

Ebben a cikkben megvitatjuk a DAO és a Repository minták közötti különbségeket.

2. DAO minta

Az adatelérési objektum minta, más néven DAO minta, az adatok perzisztenciájának absztrakciója, és közelebb tekinthető az alapul szolgáló tárolóhoz, amely gyakran táblázatcentrikus.

Ezért sok esetben a DAO-k egyeznek az adatbázis-táblákkal, lehetővé téve az adatok egyszerűbb elküldését / visszakeresését a tárolóból, elrejtve a csúnya lekérdezéseket.

Vizsgáljuk meg a DAO minta egyszerű megvalósítását.

2.1. Felhasználó

Először hozzunk létre egy alapot Felhasználó domain osztály:

public class Felhasználó {private Long id; private String felhasználónév; privát karakterlánc keresztnév; privát karakterlánc e-mail; // szerelők és beállítók}

2.2. UserDao

Ezután létrehozzuk a UserDao felület, amely egyszerű CRUD műveleteket biztosít a Felhasználó tartomány:

nyilvános felület UserDao {void create (Felhasználói felhasználó); Felhasználó olvasása (Long id); void update (Felhasználói felhasználó); void delete (String felhasználónév); }

2.3. UserDaoImpl

Utoljára létrehozzuk a UserDaoImpl osztály, amely végrehajtja a UserDao felület:

public class UserDaoImpl megvalósítja UserDao {private final EntityManager entitásManager; @Orride public void create (Felhasználói felhasználó) {entitManager.persist (felhasználó); } @Orride public User read (long id) {return entitásManager.find (Felhasználó.osztály, id); } // ...}

Itt az egyszerűség kedvéért a JPA-t használtuk EntityManager interfész, hogy kölcsönhatásba léphessen az alapul szolgáló tárolóval, és adatelérési mechanizmust biztosítson a Felhasználó tartomány.

3. Adattár minta

Eric Evans könyve szerint Tartományvezérelt tervezés, a „Az adattár a tárolás, visszakeresés és keresési viselkedés beágyazásának mechanizmusa, amely objektumok gyűjteményét emulálja.”

Hasonlóképpen szerint Vállalati alkalmazás architektúra mintái, azt „Közvetít a tartomány és az adat leképezési rétegek között egy gyűjteményszerű felület segítségével a tartományi objektumok eléréséhez.”

Más szavakkal, egy adattár adatokkal is foglalkozik, és elrejti a DAO-hoz hasonló lekérdezéseket. Ugyanakkor magasabb szinten helyezkedik el, közelebb az alkalmazás üzleti logikájához.

Következésképpen a tár egy DAO segítségével lekérheti az adatokat az adatbázisból és feltölthet egy tartományi objektumot. Vagy előkészítheti az adatokat egy tartományi objektumból, és a DAO használatával elküldheti azokat egy tároló rendszernek a tartósság érdekében.

Vizsgáljuk meg a. Repository mintájának egyszerű megvalósítását Felhasználó tartomány.

3.1. UserRepository

Először hozzuk létre a UserRepository felület:

nyilvános felület UserRepository {User get (Long id); void add (Felhasználói felhasználó); void update (Felhasználói felhasználó); void remove (Felhasználói felhasználó); }

Itt felvettünk néhány általános módszert, mint például kap, hozzá, frissítés, és eltávolítani dolgozni a tárgyak gyűjtésével.

3.2. UserRepositoryImpl

Ezután létrehozzuk a UserRepositoryImpl osztály, amely a UserRepository felület:

public class UserRepositoryImpl implementálja a UserRepository {private UserDaoImpl userDaoImpl; @ Nyilvános felhasználó felülbírálása get (Hosszú id) {Felhasználó felhasználó = userDaoImpl.read (id); visszatérő felhasználó; } @Orride public void add (Felhasználó felhasználó) {userDaoImpl.create (felhasználó); } // ...}

Itt használtuk a UserDaoImpl adatok küldésére / visszakeresésére az adatbázisból.

Eddig azt mondhatjuk, hogy a DAO és a repository implementációi nagyon hasonlóak, mert a Felhasználó osztály vérszegény tartomány. A tárház pedig csak egy újabb réteg az adatelérési réteg (DAO) felett.

A DAO azonban tökéletes jelöltnek tűnik az adatokhoz való hozzáféréshez, és az adattár ideális módja az üzleti felhasználás megvalósításának.

4. Adattár minta több DAO-val

Az utolsó állítás egyértelmű megértése érdekében fokozzuk a kifejezést Felhasználó domain egy üzleti felhasználási eset kezelésére.

Képzelje el, hogy egy felhasználó közösségi média profilját szeretnénk elkészíteni Twitter-tweetjeinek, Facebook-bejegyzéseinek és egyebek összesítésével.

4.1. Csipog

Először létrehozzuk a Csipog osztály néhány tulajdonsággal, amelyek tárolják a tweet információkat:

public class Tweet {private String email; privát karakterlánc tweetText; private Date dateCreated; // szerelők és beállítók}

4.2. TweetDao és TweetDaoImpl

Akkor, hasonlóan a UserDao, létrehozzuk a TweetDao felület, amely lehetővé teszi a tweetek beolvasását:

nyilvános felület TweetDao {List fetchTweets (String email); }

Hasonlóképpen létrehozzuk a TweetDaoImpl osztály, amely biztosítja a fetchTweets módszer:

public class TweetDaoImpl implementálja a TweetDao {@Orride public list fetchTweets (String email) {List tweets = new ArrayList (); // hívja meg a Twitter API-t és készítse elő a Tweet objektumvisszahelyezési tweeteit; }}

Itt felhívjuk a Twitter API-kat, hogy az összes e-mailt a felhasználó e-mailje segítségével lehívja.

Tehát ebben az esetben a DAO harmadik féltől származó API-k segítségével biztosít hozzáférési mechanizmust.

4.3. Fokozza Felhasználó Tartomány

Végül hozzuk létre a UserSocialMedia alosztályunk Felhasználó osztály vezetni egy listát a Csipog tárgyak:

public class A UserSocialMedia kiterjeszti a User {private List tweetjeit; // szerelők és beállítók}

Itt, a mi UserSocialMedia osztály egy komplex tartomány, amely a. tulajdonságait tartalmazza Felhasználó domain is.

4.4. UserRepositoryImpl

Most frissítjük a verziónkat UserRepositoryImpl osztály nyújtani a Felhasználó domain objektum a tweetek listájával együtt:

public class UserRepositoryImpl implementálja a UserRepository {private UserDaoImpl userDaoImpl; privát TweetDaoImpl tweetDaoImpl; @ Nyilvános felhasználó felülírása get (Hosszú azonosító) {UserSocialMedia user = (UserSocialMedia) userDaoImpl.read (id); Lista tweetek = tweetDaoImpl.fetchTweets (user.getEmail ()); user.setTweets (tweetek); visszatérő felhasználó; }}

Itt a UserRepositoryImpl kivonja a felhasználói adatokat a UserDaoImpl és a felhasználó tweetei a TweetDaoImpl.

Ezután összesíti mindkét információkészletet, és megadja az UserSocialMedia osztály, amely praktikus üzleti célra. Ebből kifolyólag, egy adattár a DAO-kra támaszkodik a különféle forrásokból származó adatok eléréséhez.

Hasonlóképpen javíthatjuk a mi Felhasználó domain a Facebook-bejegyzések listájának vezetéséhez.

5. A két minta összehasonlítása

Most, hogy láttuk a DAO és a Repository mintázatának árnyalatait, foglaljuk össze a különbségeket:

• A DAO az adatok perzisztenciájának absztrakciója. Az adattár azonban tárgyak gyűjteményének absztrakciója
• A DAO egy alacsonyabb szintű koncepció, közelebb a tárolórendszerekhez. A Tárház azonban egy magasabb szintű fogalom, közelebb áll a Domain objektumokhoz
• A DAO adat leképezési / hozzáférési rétegként működik, elrejtve a csúnya lekérdezéseket. A lerakat azonban egy réteg a tartományok és az adatelérési rétegek között, amely elrejti az adatok bonyolítását és egy tartományi objektum előkészítését
• A DAO nem valósítható meg lerakat használatával. Ugyanakkor egy adattár DAO-t használhat az alapul szolgáló tár eléréséhez

Továbbá, ha vérszegény domainünk van, akkor a tár csak DAO lesz.

Ezenkívül a lerakat mintája a tartományvezérelt kialakítást ösztönzi, könnyen megértve az adatszerkezetet a nem technikai csoporttagok számára is.

6. Következtetés

Ebben a cikkben a DAO és a Repository minták közötti különbségeket tártuk fel.

Először megvizsgáltuk a DAO minta alapvető megvalósítását. Ezután hasonló megvalósítást láttunk a Repository mintával.

Végül megvizsgáltunk egy tárolót, amely több DAO-t használt, növelve a tartomány képességeit egy üzleti felhasználási eset megoldására.

Ezért arra a következtetésre juthatunk, hogy a lerakat mintája jobb megközelítést bizonyít, amikor az alkalmazás adatközpontúról üzleti orientáltra vált.

Szokás szerint az összes kód implementáció elérhető a GitHubon.