Domanda

Sto cercando di costruire la mia prima applicazione CRUD e non capisco se dovrei usare un oggetto contenente gettici e setter separati.

Considerando che abbiamo il Zend Framework Quick Start Tutorial con una struttura modello contenente:

  • Gateway
  • Datamapper
  • Oggetto dominio (classe modello)

Se l'oggetto di dominio (come presentato sul tutorial di Zend Quick Start) è costituito da solo getter e setter, è un anti-pattern? In un certo senso, stiamo dividendo inutilmente l'oggetto di dominio con uno script di transazione?

Si prega di avvisare.

È stato utile?

Soluzione

Gli oggetti di dominio sono separati dalla logica aziendale del software. Questa è un'idea importante di Programmazione procedurale.

Tuttavia, questo modello è considerato un candidato per un anti-pattern da alcuni sviluppatori, il che significa che potrebbe essere una pratica inefficace.

In effetti potresti prendere in considerazione gli svantaggi

  • Il tuo modello è meno espressivo, i getter e i setter non sono davvero buoni per descrivere il modello
  • Il codice è più difficile da riutilizzare, si ottiene un codice duplicato tra i tuoi script transazionali
  • Devi usare involucri che nascondono la struttura dei dati effettivi (quindi forse non realmente OOP)
  • C'è sempre un accesso globale alle entità

Penso che il punto più interessante da considerare sia che gli oggetti del modello di dominio non possono assicurare la loro correttezza in qualsiasi momento. Perché la loro mutazione avviene in strati separati.

Ho lavorato anche su un'applicazione CRUD con Zend Framework. La chiara separazione tra logica e dati è davvero eccezionale, ma quando progredisci ti rendi conto che la quantità di livelli e mapper diventa sempre più grande. Prova a riutilizzare il tuo codice il più possibile ed evita la duplicazione.

Altri suggerimenti

Il modello di dominio anemico è un antim-paterno solo se si sta cercando di costruire un modello di dominio vero (noto anche come modello di dominio dal design guidato dal dominio) e finire con entità con solo stato e senza comportamento.

Per una semplice applicazione CRUD un modello di dominio anemico è probabilmente una migliore pratica, soprattutto quando hai un framework che rende il tuo lavoro molto semplice.

Vedi l'articolo di Martin Fowler su Modello di dominio anemico e anche L'articolo di Greg Young.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top