Come funzionano i livelli di dominio, repository e servizio VS modello DAO originale?

Question

Come funzionano i livelli di dominio, repository e servizio VS modello DAO originale?

#1 da (1 voti)

1

Ciao ingegneri del software,

Quindi sono un programmatore. Non un "ingegnere". Quando faccio OOP, per lo più creo classi e interfacce nel modo che voglio. Non seguo alcun modello di design ... MA ora, non solo voglio migliorare ma ho anche bisogno di scrivere un software che non sarà gestito da me ...

Ho letto questo libro un metodo per organizzare le lezioni. Dicono che, per i tuoi dati, dividi l'applicazione nei seguenti livelli: Dominio (o Modello); Persistenza (o repository) e servizio.

Quindi il dominio contiene fondamentalmente classi POJO. All'interno del Dominio, c'è un altro pacchetto per il Repository (le sue interfacce e le loro implementazioni)
Il servizio contiene le interfacce e le loro implementazioni MA qui, le classi di implementazione dei servizi chiamano oggetti del repository e tipo di ripetere i loro metodi . Ma hanno anche detto che più la logica aziendale è complessa, altri metodi possono essere aggiunti alle classi di servizio. Quindi il repository è solo per CRUD e il servizio è lì per dare accesso a CRUD + in base alla logica aziendale ...

L'ho capito bene? Ma perché usano tutte quelle interfacce? Solo implementazioni sarebbero sufficienti, a mio avviso. Perché assomiglia a DAO? L'unica differenza qui è che non vedo dove può essere adattata l'implementazione di un database diverso come fa DAO factory ...

Puoi aiutarmi a capire meglio il dominio, la persistenza, l'architettura dei servizi?

domain-driven-design design-patterns

posta Kurt Miller 25.11.2017 - 13:06

fonte

1 risposta

Leggi altre domande sui tag domain-driven-design design-patterns

Qual è il modo giusto di implementare il servizio che raccoglie dati da più servizi? Il modo più comodo per implementare i modelli utilizzati dal livello di accesso al servizio di un'applicazione Xamarin

score 1 · Answer 1

The Service contains interfaces and their implementations BUT here, services implementation classes call Repository objects and kind of repeat their methods.

Quindi il libro non lo spiega correttamente. Lo scopo del repository è di fornire metodi CRUD . Lo scopo dell'implementazione dei servizi è quello di fornire metodi che incarnino le operazioni commerciali.

Ad esempio, il metodo PrintInvoice() nell'implementazione dei servizi deve recuperare l'intestazione della fattura, gli elementi pubblicitari della fattura, l'indirizzo di spedizione e l'indirizzo di fatturazione dal repository.

Il passaggio dei metodi CRUD attraverso il livello di servizio fornisce separazione rigorosa dei livelli, ma non mi piace perché esso inquina il livello di servizio con metodi non necessari, metodi che posso semplicemente andare al repository per .

Why do they use all those interfaces?

Per consentire implementazioni diverse. Senza l'interfaccia verrai legato a una singola implementazione. Avere interfacce ti consente, ad esempio, di sostituire l'implementazione di lavoro con uno stub o un mock a scopo di test.