Il modello DataMapper rompe MVC?

Question

Ho letto molti framework PHP, in particolare Zend Framework, ma mi sto confondendo sul modo corretto di andare avanti.

Zend Framework non utilizza ActiveRecords ma utilizza invece il modello Table Data Gateway e Row Data Gateway e utilizza un DataMapper per mappare il contenuto del Row Data Gateway sul modello, poiché ActiveRecord si interrompe quando i modelli non hanno un mapping 1: 1 alle tabelle del database. C'è un esempio di questo nel Guida rapida di Zend.

Per me, il loro esempio sembra molto gonfio con un sacco di getter e setter dappertutto. Mi sono imbattuto in vari post di blog su Domain Driven Design sostenendo che l'utilizzo di così tanti getter e setter è una cattiva pratica perché espone tutti i dati del modello interno all'esterno, quindi non ha alcun vantaggio rispetto agli attributi pubblici. Ecco un esempio .

La mia domanda: se rimuovi quei getter e setter, come renderizzerai le tue visualizzazioni? Ad un certo punto i dati devono colpire la vista in modo da poter effettivamente mostrare qualcosa all'utente. Seguire il consiglio DDD sembra spezzare la separazione tra M e V in MVC. Seguire l'esempio di MVC e Zend sembra rompere DDD e mi lascia scrivere un sacco di getter, setter e DataMapper per tutti i miei modelli. Oltre a essere un sacco di lavoro, sembra anche violare il DRY.

Gradirei davvero alcuni (link a) buoni esempi o maggiori informazioni su come tutto si adatta. Sto cercando di migliorare le mie competenze di architettura e design qui.

Answer 1

Utilizzando Value Objects, è possibile eliminare alcuni di questi metodi di impostazione pubblica. Ecco una descrizione di la differenza tra Entità e Oggetti valore . Gli oggetti valore sono immutabili e spesso legati a un'entità. Se passi tutti i valori con il costruttore, non è necessario impostare queste proprietà dal codice esterno.

Qualcosa in più, non direttamente correlato a una risposta, ma più focalizzato su DDD:

(Dichiarazione di non responsabilità: l'unica cosa che so di Zend Framework è ciò che ho letto nell'articolo collegato.) Zend Framework utilizza DataMappers invece di Repository. È davvero DDD-ish? Bene, l'interpretazione di Fowler di un repository potrebbe dire di no. Tuttavia, Eric Evans afferma che un repository DDD può essere molto semplice. Nella sua forma più semplice, un repository è un DataMapper (vedi il libro DDD). Per qualcosa di più complesso e ancora DDD, vedi l'articolo di Fowler. DDD ha un repository concettuale che può differire dalla definizione del modello.

Vi esorto a continuare a leggere su Domain-Driven Design. Penso che ci sia un difetto nell'ipotesi che getter e setter violino DDD. DDD si concentra sul modello di dominio e sulle migliori pratiche per raggiungere questo obiettivo. Gli accessori sono solo un piccolo dettaglio.

Answer 2

Non è necessario implementare tutti i getter / setter, è possibile utilizzare__get () e __set (). Qual è il problema allora?

Answer 3

Dalla mia lettura del post, la domanda è più filosofica piuttosto che pratica.

Non ho il tempo di scrivere in profondità, ma ecco i miei due centesimi. Mentre sono d'accordo che vuoi limitare il numero di richieste get e set perché una classe dovrebbe nascondere i suoi interni, devi anche tenere conto del fatto che Java e PHP sono strumenti diversi e hanno scopi diversi. Nell'ambiente Web le classi vengono create e rimosse con ogni richiesta e pertanto il codice che si scrive non dovrebbe dipendere da classi enormi. Nell'articolo che hai sottolineato l'autore suggerisce di posizionare la logica della vista nella classe. Questo probabilmente non ha senso sul web poiché probabilmente vorrò presentare la vista in più formati (rss, html, ecc ...). L'uso dei metodi di accesso (get & amp; set) è quindi un male necessario. Vuoi ancora usarli pensieroso in modo da non spararti al piede. La chiave è cercare di fare in modo che le tue classi facciano il lavoro per te invece di cercare di costringerle a fare il lavoro esternamente. Accedendo alle tue proprietà con un metodo anziché direttamente nascondi gli interni che è ciò che desideri.

Ancora una volta, questo post potrebbe usare alcuni esempi, ma non ho il tempo in questo momento.

Qualcun altro può fornire alcuni esempi del perché i metodi di accesso non sono malvagi?

Answer 4

Ci sono due approcci qui: quello che chiamo l'approccio "non dire" non chiede "e l'altro è l'approccio ViewModel / DTO. Sostanzialmente le domande ruotano attorno a qual è il "modello" a tuo avviso. Dire non chiedere richiede che l'unico modo in cui un oggetto possa essere esternalizzato sia dall'oggetto stesso. In altre parole, per renderizzare un oggetto, avresti un metodo di rendering, ma quel metodo di rendering avrebbe bisogno di parlare con un'interfaccia. Qualcosa del genere:

class DomainObject {
   ....
   public function render(DomainObjectRenderer $renderer) {
        return $renderer->renderDomainObject(array $thegorydetails);
   }
}

Nel contesto di Zend Framework, è possibile sottoclassare Zend_View e far sì che la sottoclasse implementi questa interfaccia.

L'ho già fatto prima, ma è un po 'ingombrante.

La seconda opzione è convertire il tuo modello di dominio in un oggetto ViewModel, che è come un oggetto semplificato, appiattito, "quotato in sequenza". visualizzazione dei tuoi dati, personalizzata per ogni vista specifica (con un ViewModel per vista) e, al ritorno, converti i dati POST in un EditModel.

Questo è un modello molto popolare nel mondo ASP.NET MVC, ma è anche simile alla classe "DTO" modello utilizzato per trasferire dati tra "strati" in un'applicazione. Dovresti creare mappatori per fare il lavoro sporco per te (non diversamente da un DataMapper, in realtà). In PHP 5.3, puoi usare la riflessione per modificare le proprietà private, quindi il tuo DomainObject non ha nemmeno bisogno di esporsi!

Answer 5

L'implementazione di getter e setter ha due vantaggi, ai miei occhi:

1. Puoi scegliere quali proprietà rendere pubbliche, quindi non devi necessariamente esporre tutti gli interni del modello
2. Se usi un IDE con il completamento automatico, tutte le proprietà disponibili saranno a TAB quando inizi a digitare " get " o "impostare" & # 8212; questo da solo è una ragione sufficiente per me.