Domanda di progettazione dell'architettura di cipolla

Naviga le tue risposte
3

Recentemente ho iniziato a lavorare su un nuovo progetto in cui il team stava prendendo in considerazione l'uso dell'architettura cipolla, che non conoscevo molto bene, quindi ho iniziato a leggerlo.

L'applicazione è un semplice convertitore di formato 3D. Legge un database SQL, converte i dati e poi scrive il nuovo formato in un altro database MySql. Il primo database è molto complesso, ma non penso che sia il caso. Il concetto di applicazione è molto semplice: leggi da A, converti, scrivi in B. Non avrò alcun servizio o infrastruttura speciale per questo.

Sarà un'applicazione desktop.

Sulla base di questi fatti, chiedo:

  1. Tutto ciò che ho letto su onion è correlato alle applicazioni web. C'è qualche motivo particolare per cui non è molto popolare in un'applicazione desktop?

  2. Ho letto anche che è più indicato nelle imprese complesse. Sarebbe efficace e avrà vantaggi pratici su un'applicazione così semplice?

  3. Se andiamo per il percorso della cipolla, cosa sarebbe nel livello del dominio? Sei libero di commentare i seguenti livelli:

    L1) Source Layer: rappresenterà i dati nel database di origine
    L2) Output Layer: rappresenterà i dati nel database di output
    L3) Database Reader Layer: sarà responsabile della lettura del database di origine e del popolamento del livello 1
    L4) Converter Layer: sarà un adattatore che riceverà Layer 1 e popolerà il Layer 2 con i dati convertiti
    L5) Database Writer Layer: scriverà il Layer 2 nel database

    I livelli 1 e 2 sarebbero il mio dominio?
    I livelli 3 e 5 sarebbero infrastruttura?
    E il livello 4 sarebbe un servizio di applicazione o dominio?

posta RBasniak 26.05.2016 - 21:34
fonte

2 risposte

4

Non sono così sicuro che l'architettura della cipolla abbia molto senso in questo caso.

Ciò che è possibile tenere dall'architettura della cipolla è il principio che il core dell'applicazione (i traduttori) dovrebbe essere disaccoppiato dall'accesso ai dati. Ma nel complesso il tuo requisito è molto più simile a una pipeline.

read -> transform -> write

Ora, leggere e scrivere sono impuri (difficili da testare). Transform potrebbe essere puro (facile da testare) se non chiama direttamente la scrittura. Quindi, se disaccoppiate facendo in modo che il core della tua app (trasformi) restituisca i dati da scrivere, o pubblichi in una coda / osservabile / bus, allora hai effettivamente isolato il tuo core e reso testabile. Questo è il principio dell'architettura della cipolla.

Informazioni sulle tue domande:

  1. Generalmente le applicazioni server hanno una logica aziendale complessa, ma non c'è motivo per cui il modello non debba applicarsi a nessun'altra applicazione di tipo

  2. Ci sono sempre dei vantaggi nel separare la funzionalità principale dalle interfacce ad altri sistemi

  3. Il livello di dominio sarebbero le entità aziendali che i tuoi DB in definitiva dovrebbero rappresentare

Se si sceglie o meno di avere un tipo di oggetto "comune" e 2 tipi di oggetto che assomigliano più da vicino alla rappresentazione nel database, a mio parere, è una possibilità ma non un requisito rigoroso; dipende solo dal tipo di dati. È possibile utilizzare il modello relazionale come modello di dominio e convertirlo nel modello denormalizzato. (Vedo molte applicazioni che duplicano oggetti identici su più livelli, finendo con molte rappresentazioni per gli stessi dati, questo non è un buon IMO di progettazione.)

    
risposta data 31.05.2016 - 23:13
fonte
1

Il tuo database di input e il tuo database di output sono ciascuno al livello 1.

Il Layer 2 conterrà due Translators, uno per ogni Database al Livello 1, che traduce tra i particolari oggetti del database e un tipo di oggetto "comune" (o "universale").

Il livello 3, la tua "applicazione", manipola gli oggetti comuni.

Potresti vederlo come una pipeline piegata a forma di "U".

    
risposta data 26.05.2016 - 22:25
fonte

Leggi altre domande sui tag

Il significato di unificato in UML stati applicativi della GUI e polimorfismo