DDD e collezioni e paging di modelli correlati?

Question

DDD e collezioni e paging di modelli correlati?

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

2

Ho un modello ricco, dove ad es. un modello A dipende da molte entità correlate / oggetti valore. Pertanto abbiamo metodi in A per il recupero delle raccolte di oggetti correlati: getFoos() , getBars() e così via.

A un certo punto, una o più di queste raccolte correlate non dovrebbero essere recuperate con entusiasmo e, inoltre, dovrebbero essere recuperate usando la paginazione.

Non voglio "inquinare" il modello con metodi come getFoosPage(from, to, size) . Questo non fa parte del business, è parte del problema di visualizzazione.

Come devo risolvere l'impaginazione?

Successivamente, a volte ho bisogno di ottenere solo A con Foos , ma non Bars . Dovrei avere un metodo nel mio repository dicendo: getAWithFoos() ? Non mi piace che vengano restituiti A sarà popolato solo parzialmente (no boos ), e non puoi dirlo solo ispezionando il modello.

Per ora, sto pensando di costruire un modello di 'query', dove avrei diverse classi per gli scenari che mi servono, come 'AWithFoos' che contiene A e Foos correlati e così via. Ha senso?

domain-driven-design architecture

posta lawpert 27.10.2014 - 11:15

fonte

2 risposte

0

Devi prendere in considerazione il modello di caricamento lento se desideri recuperare articoli solo per richiesta

Per quanto riguarda la necessità della vista. Ho usato una soluzione diversa. Ho notato che su viste sofisticate ho bisogno di caricare molte entità che poi a loro volta hanno caricato i loro figli. Troppo lavoro sul DB / memoria di processo. Così ho creato un oggetto Report che fondamentalmente estendeva l'oggetto che può popolare il set di risultati dal risultato SQL (nel mio caso era ZF2 ResultSet ). Quindi tutto ciò che dovevo fare era:

Imposta l'SQL (join sinistro o qualsiasi cosa, chiamo viste che nascondono la complessità)
Inizia l'oggetto (passando l'adattatore)
Lavora sul set di risultati

È una query semplice, soluzione di sola lettura.

<?php

namespace MyProj\Mapper\Reports;

use Zend\Db\Adapter\Adapter;
use Zend\Db\ResultSet\ResultSet;

class AccountsWithGroupsUsersCount extends ResultSet
{
    protected $sql = 'SELECT * FROM v_accounts_with_groups_and_users_count';

    /**
     * Execute the script and initilize the users list
     * @param int $accountId
     * @param Adapter $dbAdapter
     */
    function __construct(Adapter $dbAdapter)
    {
        parent::__construct();
        $stmt   = $dbAdapter->query($this->sql);
        $result = $stmt->execute();
        $this->buffer()->initialize($result);
    }

}

risposta data 27.10.2014 - 13:16

fonte

Leggi altre domande sui tag domain-driven-design architecture

I campi devono ancora essere privati quando è necessario ristrutturare i dati? È possibile avere un polimorfismo Ad-Hoc con l'invio in runtime?

score 3 · Accepted Answer

Il "modello di query" che hai menzionato ha senso, in realtà c'è un intero approccio basato su quello (CQRS). Il lato della query esponeva le facciate dei modelli di lettura per tutti i modelli di visualizzazione su misura di fantasia di cui si ha bisogno e il lato comando ha i repository per le transazioni commerciali tramite gli aggregati.

In un'app DDD non CQRS tradizionale, non sarei scioccato nel vedere i parametri di paging e di filtraggio nei metodi repo, poiché sono anche gli oggetti di query.

Puoi anche dare un'occhiata alle Regole del disegno efficace degli aggregati di Vaughn Vernon. Tramite Aggregati più piccoli e una progettazione più attenta del dominio, risolve il tipo di problemi di caricamento e di prestazioni delle entità che sembra verificarsi.