Le migliori pratiche per il modello DAO?

Question

Ho visto molti codici utilizzare un modello di servizio-dao, non conosco l'origine di questo modello. Forza il servizio di chiamata del livello anteriore, quindi delega alcune delle attività di servizio a dao.

voglio chiedere:

1. fa DAO strato non puramente accesso ai dati correlati compito? Che dire di cose come l'incapsulamento delle eccezioni?
2. È possibile utilizzare un altro modello per sostituire questo o meglio di questo?
3. Penso che i modelli di dominio Pojo e gli script di transazione rendano complicato anche il semplice problema, è possibile eliminare completamente il livello dao?

Answer 1

Idealmente, il livello DAO "astrae" l'accesso ad alcuni sistemi di archiviazione dati (database, file system, directory LDAP, ...). Quindi in questo senso è usato solo per le attività relative all'accesso ai dati. Tuttavia, potresti anche avere un livello DAO che accede a un servizio Web o ad altri componenti esterni alla tua applicazione. Questo è il punto chiave, fornisce l'accesso ad alcuni componenti esterni.

L'idea principale è che non ci sono dettagli di implementazione del livello DAO che sfuggono agli strati superiori (isolamento). Un buon punto di partenza per riflettere su questo è: cosa dovrei fare se prevedo di sostituire il componente (un database ad esempio) a cui il livello DAO fornisce accesso? Ad esempio, si dispone di alcuni dati all'interno di file XML e si pianifica di migrare i dati in un database.

Supponiamo di avere tutti i tipi di eccezioni relative al codice XML che sfuggono al tuo livello DAO. Quindi diventa piuttosto difficile migrare il tuo livello XML a un livello di database. Tuttavia, se hai incapsulato tutti i dettagli di implementazione del tuo livello DAO, questo diventerà molto più semplice.

Alla fine, si tratta di manutenibilità del codice. Meno dipendenze si hanno sui dettagli di implementazione di un livello specifico (servizi, DAO, ...), migliore è la manutenzione del codice.

Answer 2

L'obiettivo principale di tale livello è fornire l'astrazione del back-end di persistenza. tuttavia, la maggior parte delle volte, a causa delle specificità del back-end di persistenza, non è possibile nascondere completamente; Un tipico esempio è la gestione delle query. Per interrogare un DB utilizzando Hibernate, scriverai una sorta di codice di query (usando HQL, query API, ...) e un paradigma totalmente diverso quando utilizzi JCR, un BigTable o qualcos'altro. Di conseguenza, la maggior parte delle volte, questo modello fallisce.

Inoltre, c'è anche il - più fastidioso - problema di DAO/DTO. Si viene quindi spinti in avanti per scrivere una prima classe contenente i dati, quindi una seconda copia dei dati dal primo senza alcun valore aggiunto solo per motivi di isolamento dei livelli.

C'è tuttavia del lavoro che è stato fatto in questo campo. Per un micro-framework che ho avviato e implementato per google-app-engine, ho creato uno little list di cosiddetti framework dao che semplifica questo codice piuttosto banale.

Avviso Ho in programma, in futuro, di essere in grado di offrire trasparenza totale attraverso la definizione del servizio Gaedo, ma è solo una speranza ;-) (e non è di interesse immediato per voi, immagino).

Answer 3

L'accesso ai dati varia in base all'origine dei dati. L'accesso alla memoria persistente, ad esempio a un database, varia notevolmente in base al tipo di archiviazione (database relazionali, database orientati agli oggetti, file flat e così via) e all'implementazione del fornitore.

Utilizzare un oggetto di accesso ai dati (DAO) per astrarre e incapsulare tutti gli accessi all'origine dati. Il DAO gestisce la connessione con l'origine dati per ottenere e memorizzare i dati.

Il DAO implementa il meccanismo di accesso richiesto per lavorare con l'origine dati. L'origine dei dati potrebbe essere un archivio persistente come un RDBMS, un servizio esterno come una borsa B2B, un repository come un database LDAP o un servizio aziendale a cui si accede tramite il protocollo Internet Inter-ORB Protocol (IIOP) CORBA o socket di basso livello. La componente aziendale che si basa su DAO utilizza l'interfaccia più semplice esposta dal DAO per i propri client. Il DAO nasconde completamente i dettagli di implementazione dell'origine dati dai suoi client. Poiché l'interfaccia esposta dal DAO ai client non cambia quando l'implementazione dell'origine dati sottostante cambia, questo modello consente al DAO di adattarsi a diversi schemi di archiviazione senza influire sui client o sui componenti aziendali. In sostanza, il DAO funge da adattatore tra il componente e l'origine dati.