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.