Quanto parte della preparazione, trasformazione e elaborazione dei dati appartiene al livello del repository?

6

Ho un caso d'uso in cui visualizzo variabili in un file PDF. Ma per arrivarci non è semplice, ma potrei fare qualcosa del genere:

/*
 * takes product model number, retrieves, processes, formats values
 * returns $variables, ready to plug-in to view with no further processing
 */
$variables = $this->repository->getVariables($model);

/*
 * View runs PDF Library code and displays variables and their values in a table
 */
$this->sendToView($variables);

Way 1 - Have Repository Fa tutto il lavoro per trasformare le variabili

all'interno di getVariables vorrei fare questi:

  1. legge i dati grezzi dalle tabelle del database (espressioni memorizzate)
  2. esegue i dati attraverso il motore di espressione (valuta le espressioni)
  3. formatta i dati numerici risultanti (cioè arrotondati a 2 punti decimali)
  4. aggiungi denominazioni (vale a dire mm o pollici)
  5. adornano i dati (metti tolleranze ingegneristiche o parole extra intorno alle variabili)
  6. raggruppare nuovamente i dati per l'utilizzo dal motore dell'API PDF (la vista)

Tutto il lavoro sarà fatto in getVariables e sendToView quindi collegherà direttamente le variabili come dirige API PDF, nessuna trasformazione necessaria

Way 2: utilizza il repository per ottenere solo dati grezzi

Di fronte all'estremo c'è solo getVariables do # 1 e le classi separate fanno le loro cose .. Potrei finire con

$expressions = $this->repository->getVariables($model);
$solveExpressions = $this->expressionEngine->process($expressions);
$formattedVars = $this->formatter->format($solvedExpressions);
$denominatedData = $this->denom->addMarkers($formattedVars);
$adornedData = $this->adorner->adorn($denominatedData);
$viewReadyData = $this->viewPreparer->prep($adornedData);
$this->sendToView($viewReadyData);

Oppure potrei mescolare e abbinare quanto sopra e inserire i metodi in varie classi ..

La mia domanda

Quanto della trasformazione, formattazione, raggruppamento, lucidatura, preparazione, ecc. dei dati va nel livello del repository?

(Ciò mi aiuterà a determinare quale sarà la manipolazione dei dati che dovrà essere eseguita al di fuori del livello del repository, e forse anche cosa si debba fare nella manipolazione dei dati nel livello vista - cioè il semplice raggruppamento dei dati per un modo più semplice di inserire in una tabella)

P.S. Cosa sto cercando di fare (manipolazione dei dati)

Senza concentrarsi sul codice, nel contesto della domanda, ciò che sto facendo è questo: a partire dalle espressioni memorizzate nel database:

a = 5
b = a + 3

Poi finisco con le espressioni risolte:

a = 5
b = 8

Poi faccio una serie o la formattazione e adornano in questo modo:

8 => 8.00 => 8.00mm => 8.00mm +/-0.01

dove durante il precedente è conservato in una forma simile a

array(
    'a' => '5.00mm +/-0.01',
    'b' => '8.00mm +/-0.01'
);

Per la vista lo trasformo in

array(
    0 => array(
        'description' => 'a',
        'value' => '5.00mm +/-0.01'
    ),
    1 => array(
        'description' => 'b',
        'value' => '8.00mm +/-0.01'
    )
);

E desidero scrivere quanto sopra nel codice OOP moderno.

    
posta Dennis 28.11.2016 - 17:02
fonte

1 risposta

3

In base ai tuoi commenti, ti consiglio vivamente di non farti ingannare dalle cosiddette best practice e altre magie. In primo luogo dovresti scegliere un modo per implementare la tua soluzione in un modo che aiuti:

  • i tuoi stakeholder / boss per raggiungere l'obiettivo aziendale utilizzando la tua soluzione: il codice in atto.
  • tu e il tuo team sarete in grado di rispondere rapidamente al problema / problema sorto, in un modo che tutti comprendono

Scrivi anche di anemia e oggetto aziendale. Per favore dimostri che ho torto, ma non riesco a percepire alcun comportamento o logica aziendale nel set di chiamate di metodo. Sembrano semplicemente effettuare una serie di trasformazione dei dati, senza alcuna convalida o altro. Ho la sensazione che sia usato per una sorta di rapporto, ma la vera intenzione non è chiara.

L'unica cosa utile che posso aiutarti è esaminare il tuo codice, catturare le aree tecniche e dividerle in moduli che hanno confini espliciti. Il Separazione dei dubbi principio di progettazione può aiutare a disegnare i confini qui:

  • Repository: ritenuto responsabile della lettura e della scrittura dei dati nel tuo archivio dati
  • Motore di espressione: valutazione dei dati
  • Formatter: formattazione e decorazione
  • Output alla visualizzazione: converti / rappresenti il precedente in un dato formato di output

Ciascuno di questi moduli dovrebbe essere responsabile della propria serie di problemi. Crea classi con i rispettivi metodi che fa rispettivamente ciò che è responsabile e niente di più . Ogni volta che incapsula queste preoccupazioni in un insieme di moduli, stai anche aumentando la coesione e potresti persino aiutare la verificabilità del tuo codice.

    
risposta data 28.11.2016 - 20:40
fonte

Leggi altre domande sui tag