Devo rendere privato il pacchetto le mie interfacce DAO?

4

Ho diverse classi DAO che implementano un'interfaccia. D'altra parte, ho classi di servizi che utilizzano queste implementazioni DAO.

Finora tutte le interfacce DAO sono pubbliche e stavo pensando se sarebbe stato meglio renderle private e inserire le classi di servizio nello stesso pacchetto in modo che fossero le uniche a poterle utilizzare.

Il motivo è perché non vorrei che i programmatori potessero utilizzare le implementazioni DAO in un controller o in un servizio Web senza utilizzare il livello di servizio. Ad esempio, un programmatore potrebbe pensare che aggiungere un nuovo ordine sia semplice come chiamare il metodo dao addOrder, ignorando che in effetti esiste un metodo di servizio che fa di più.

Cosa ne pensate?

    
posta Oscar 11.03.2013 - 23:13
fonte

2 risposte

4

In primo luogo, suggerirei di impacchettare questi due in modo indipendente e di offrire una documentazione adeguata su quale sia lo scopo di ogni biblioteca. Ti darà più flessibilità a lungo termine, perché potresti dover bypassare il livello di servizio a un certo punto o utilizzare il livello dati come libreria a funzionalità comune per altri progetti.

Detto questo, sono d'accordo sul fatto che dovresti limitare l'accesso ai DAO, specialmente per evitare la manipolazione diretta del tuo data store. Tuttavia, questo si applica alla versione concreta dei DAO (la tua domanda è vaga su questo aspetto). Avere pubblico le interfacce potrebbe essere utile per altri sviluppatori per fornire la propria implementazione nel caso in cui vogliano utilizzare un altro tipo di archiviazione dei dati (presupponendo che si fornisca un modo per iniettare DAO nel proprio livello di servizio). Questo dovrebbe seguire bene con il Principio Aperto / Chiuso .

    
risposta data 11.03.2013 - 23:39
fonte
3

Capisco da dove vieni dal punto di vista dell'incapsulamento, e non penso necessariamente che sia una cattiva idea, anche se mi chiedo quanto sia importante questo alla fine. Alcuni punti importanti:

Architettura orientata ai servizi o orientata ai componenti

Hai menzionato in modo specifico che i tuoi clienti dei tuoi servizi otterranno in qualche modo librerie e possibilmente il tuo codice sorgente. In genere, ciò contrasta con SOA in quanto i tuoi clienti in genere non sapranno nulla dell'architettura sottostante del servizio (né dovrebbero preoccuparsene).

Tide goes in, tide goes out. Never a missed step... you can't explain that - Bill O'Reilly

Idealmente, i tuoi utenti del servizio dovrebbero essere tanto ignoranti rispetto alle specifiche dei tuoi servizi quanto il nostro caro amico Bill O'Reilly è sulle maree. La richiesta entra, la richiesta si spegne, non è possibile spiegarlo.

D'altro canto, se si ha un'architettura a componenti in generale, mentre i consumatori possono avere fisicamente il componente, non dovrebbero mai usarlo al di fuori delle interfacce predesignate o comunque si hanno problemi più profondi.

La separazione dello strato DAO dovrebbe essere per poco più che dissociare l'acquisizione dei dati dalla logica aziendale, a esclusivo vantaggio del componente e di quelli incaricati di svilupparlo e mantenerlo.

Basato transazionale rispetto all'oggetto orientato

I sistemi basati su transazioni operano su transazioni e sessioni di varie richieste e risposte individuali. Essendo questo come la scelta dell'architettura che hai deciso per la tua applicazione, l'importanza dei concetti fondamentali orientati agli oggetti è discutibile per questa particolare situazione.

Le classi non denotano nulla di più delle varie implementazioni comportamentali per varie aree funzionali della tua applicazione, tuttavia quando sono distribuite su un server delle applicazioni sono prive di stato significativo, agiscono più come i singleton. In realtà questo è in genere esattamente ciò che sono se accoppiato con un quadro di Iniezione di dipendenza.

In un vero design e architettura OO, un framework DI per le classi Data Access e Business Logic sono più o meno inietti singletons dove il comportamento richiesto è, ma senza stato questo è veramente OO per cominciare?

Certamente DI può essere utile per classi orientate agli oggetti che possono essere preconfigurate con vari stati, ma non qui. Quindi, sapendo che, il concetto di incapsulamento è essenzialmente discutibile dato che le tue classi DAO sono probabilmente iniettate dove devono comunque essere in mente Reflection.

    
risposta data 12.03.2013 - 00:01
fonte

Leggi altre domande sui tag