Design pattern per l'astrazione dell'interazione tra più risorse

Question

Design pattern per l'astrazione dell'interazione tra più risorse

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

2

Finora ho creato applicazioni che astraggono le operazioni dell'entità dati dietro l'utilizzo di Repositories . Ciascuno di essi incapsulerebbe il dominio che corrisponde alla loro entità definita. Ad esempio: UserRepository incapsulerebbe la logica di dominio relativa all'entità User , come changePassword(old,new) , createAccount(email,password , retrieveAllFriendsForUser(id) e così.

Ma ci sono casi in cui hai bisogno di più risorse per interagire e astrarre quella logica in un repository di un'altra entità sembra maleodorante. Ad esempio: l'acquisto di un Item richiederebbe di creare un Quotation , creare un Payment , riducendo il ItemQuantity da Inventory e così via; gestire tale operazione in ItemRepository significherebbe che l'implementazione dipenderebbe da QuotationRepository , PaymentRepository , ecc ...

Ho letto in precedenza sugli schemi Business Facade e dell'unità di lavoro , ma dopo averli nuovamente letti sembra che non siano mirati a questo specifico multiplo interazione delle risorse , ma piuttosto mirato a accesso semplificato a blocchi di codice e gestione di operazioni atomiche , rispettivamente.

Che cos'è un modello di progettazione per la gestione dell'interazione di più risorse e, se possibile, un codice di esempio rapido che lo integra.

architecture design-patterns

posta Christopher Francisco 20.01.2016 - 19:13

fonte

2 risposte

Leggi altre domande sui tag architecture design-patterns

Ha senso avere un limite di thread specificato dall'utente? Qual è stato il motivo alla base dell'utilizzo delle virgolette nelle istruzioni di importazione di Google?

score 3 · Answer 1

Penso che tu stia confondendo alcune idee diverse qui.

Il repository viene solitamente utilizzato come un'astrazione tra il codice che consuma e il componente di persistenza. I metodi tipici su un UserRepository potrebbero essere

interface UserRepository {
    void save(User user);
    User getById(UserId id);
}

Le operazioni per cambiare l'utente sarebbero normalmente implementate sull'utente stesso

interface User {
    void changePassword(String newPassword);
}

Gli oggetti usati per coordinare le preoccupazioni distribuite tra più componenti sono di solito costruiti con riferimenti ai componenti. Troverai spesso che una Fabbrica è usata per creare gli oggetti; incluse le fabbriche che chiamano in altre fabbriche per ottenere le singole parti.

Quando le specifiche dell'oggetto da creare sono particolarmente complicate, è probabile che un Builder entri nell'immagine, come meccanismo per raccogliere i vari argomenti che saranno necessari per creare il grafico dell'oggetto.

Le cose diventano più complicate quando si hanno a che fare con oggetti che sono archiviati in repository separati. Quello che probabilmente vedrai in questo caso sono operazioni atomiche sugli oggetti, che inviano messaggi asincroni tra loro per comunicare cambiamenti.

Ad esempio: un cliente effettua un ordine per alcuni prodotti. Il nuovo stato dell'ordine viene salvato nel repository degli ordini. Un gestore di processi osserva il nuovo ordine e invia un messaggio asincrono al componente di magazzino per spedire l'ordine. Il magazzino appropriato viene caricato dall'archivio del magazzino per aggiornare l'inventario in magazzino, ecc. E salvare tali informazioni. Nel rimuovere l'inventario dal magazzino, il magazzino osserva che lo stock disponibile è sceso al di sotto del limite di riserva, quindi viene inviato un altro messaggio asincrono per segnalarlo. Un altro componente raccoglie questo messaggio e inizia il lavoro di ordinare più scorte dal fornitore, ecc.

score 2 · Answer 2

Ciò che descrivi è la logica aziendale. L'acquisto di un articolo è una transazione commerciale. Questo appartiene al livello di servizio.

Ricorda che il livello del repository funge da facciata per la persistenza ed esiste per astrarre i dettagli sottostanti del tuo meccanismo di persistenza dal resto della tua applicazione.

Il livello Servizio, al contrario, espone la logica aziendale che utilizza i repository. Il livello di servizio dovrebbe coordinare le diverse transazioni dai diversi repository