Implementazione di un DAO compatibile con NoSQL e RDBMS

Question

Implementazione di un DAO compatibile con NoSQL e RDBMS

#1 da (3 voti)
#2 da (0 voti)

1

Quale sarebbe il modo corretto di progettare un DAO su cui l'implementazione si rivolge per la prima volta a un database MS SQL con un modello STAR, ma i requisiti aziendali specificano che l'applicazione deve essere sufficientemente flessibile da poter essere migrata se necessario, in un database NoSQL in futuro. Quale tipo di NoSQL, nessuna idea ...

La mia confusione è che non riesco a capire come potrei costruire DAO indipendenti per le tabelle STAR Dimensions e Facts che potrebbero poi essere scambiate per un modello completamente diverso che potrebbe non essere nemmeno orientato alla tabella (riak / mongo / qualunque) .

Quindi ,

Dovrei creare DAO che invece di astrarre la tabella , astrae le operazioni CRUD - ad esempio crea IDaoInsert che può quindi essere implementato come SQLInsertDaoImpl e MongoInsertDaoImpl , ciascuno con una logica del modello completamente diversa ecc.

o

Dovrei semplicemente creare il tipico design DAO la cui interfaccia sarebbe qualcosa come IDaoCustomerDimension e l'implementazione SqlDaoCustomerDimesionImpl e MongoDaoCustomerDimentionImpl rispettivamente?

Hibernate / Etc non rientra nello scopo di questa domanda per il momento.

java design-patterns orm data-modeling dao

posta Carlos 16.01.2015 - 21:25

fonte

2 risposte

Leggi altre domande sui tag java design-patterns orm data-modeling dao

Perché usare la pausa è considerata una cattiva pratica? [duplicare] Dove si trova generalmente il Principio di sostituzione di Liskov in diverse liste di parametri del costruttore?

score 3 · Answer 1

La tua architettura dovrebbe assomigliare a questa:

Data source <--> Data source driver <--> CRUD interface <--> Application

Avrai bisogno di un'implementazione del driver dell'origine dati per ogni tipo di fonte di dati. L'interfaccia CRUD sarà la stessa indipendentemente dall'origine dati.

Nota che puoi avere più di semplici metodi CRUD. Ad esempio, potresti voler restituire le raccolte. Assicurati che qualsiasi cosa tu faccia sul lato Data Source sia traducibile con la tua API sul lato CRUD per tutte le possibili origini dati.

score 0 · Answer 2

Questo è davvero dipendente, ad esempio se prendi entità gestite in JPA, non utilizzerai quasi mai il metodo di aggiornamento direttamente, poiché l'aggiornamento del modello sarà automaticamente trasferito al database sul commit.

D'altro canto, avere JPA mentre non si utilizzano le entità gestite convertendo DTO in modello di business è molto inefficiente.

Inoltre, ci sono documenti NoSQL database, valore-chiave, ....

A mio parere, basta progettare un'interfaccia di servizio adeguata e un'implementazione che utilizzi correttamente gli oggetti ORM e gli opportuni test di JUnit Suite. Quindi, se devi cambiare, riscrivi lo stesso servizio con il proprio livello DAO per NoSQL quando sarà il momento contro la stessa suite di test JUnit.