Modelli di dominio (PHP)

3

Ho programmato in PHP da diversi anni e ho, in passato, adottato metodi per gestire i dati all'interno delle mie applicazioni.

Ho costruito il mio MVC in passato e ho una ragionevole comprensione di OOP in php, ma so che la mia implementazione richiede un lavoro serio.

In passato ho utilizzato una relazione is-a tra un modello e una tabella di database. Ora so, dopo aver fatto alcune ricerche, che questa non è la migliore strada da seguire. Per quanto ho capito, dovrei creare modelli a cui non interessa il database sottostante (o qualsiasi altro meccanismo di archiviazione da utilizzare), ma solo preoccuparsi delle loro azioni e dei loro dati.

Da questo ho stabilito che posso creare modelli di diciamo per esempio una Persona un oggetto di questa persona potrebbe avere alcuni Bambini (figli umani) che sono anche oggetti Person tenuti in un array (con metodi addPerson e removePerson, accettando un Oggetto Persona).

Potrei quindi creare un PersonMapper che potrei usare per ottenere una persona con uno specifico 'id', o per salvare una persona.

Ciò potrebbe quindi cercare i dati di relazione in una tabella di ricerca e creare gli oggetti figli associati per la Persona che è stata richiesta (se ce ne sono) e allo stesso modo salvare i dati nella tabella di ricerca sul comando di salvataggio.

Questo sta spingendo i limiti alle mie conoscenze .....

E se volessi modellare un edificio con diversi livelli e stanze diverse all'interno di quei livelli? Cosa succede se volessi inserire alcuni oggetti in quelle stanze?

Creerei una classe per la costruzione, il livello, la stanza e l'elemento

con la seguente struttura.

la costruzione può avere 1 o molti oggetti di livello tenuti in un livello di matrice può avere 1 o più oggetti di stanza tenuti in una stanza di matrice possono avere 1 o molti oggetti di oggetti tenuti in una matrice

e mappatori per ogni classe con mappatori di livello superiore che usano i mappatori figli per popolare gli array (su richiesta dell'oggetto di livello superiore o carico pigro su richiesta)

Questo sembra accoppiare strettamente i diversi oggetti anche se in una direzione (cioè un pavimento non ha bisogno di essere in un edificio ma un edificio può avere livelli)

È questo il modo corretto di fare le cose?

All'interno della vista voglio mostrare un edificio con un'opzione per selezionare un livello e quindi mostrare il livello con un'opzione per selezionare una stanza, ecc., ma potrei anche voler mostrare una struttura ad albero degli oggetti nel edificio e in che livello e stanza ci sono.

Spero che abbia senso. Sto semplicemente lottando con il concetto di nidificare gli oggetti l'uno dentro l'altro quando il concetto generale di oop sembra essere quello di separare le cose.

Se qualcuno può aiutarlo sarebbe davvero utile.

Grazie mille

    
posta Calum Bulmer 11.09.2012 - 17:54
fonte

1 risposta

1

OOP non intende semplicemente "cose separate". Riguarda l'organizzazione, l'intento e la riusabilità (quando appropriato). Dai un'occhiata a Domain Driven Design (DDD). Nello specifico, identificando dove sono i tuoi "Oggetti Valore", le tue "Entità" e quali "Servizi / Fabbriche / Repositi" sono necessari per supportarli per ottenere dove devi essere.

In risposta alla tua qeustion:

Would I create a class for building, level, room and item with the following structure

-Sì, sembra che quelli sarebbero i tuoi modelli

building can have 1 or many level objects held in an array level can have 1 or many room objects held in an array room can have 1 or many item objects held in an array

-Che suona bene, l'edificio sarebbe la tua Entità, perché ogni edificio è unico e ha un'esistenza distinta, al contrario di un "oggetto" o "stanza" che ha un valore chiaramente definito, ma non esiste un'altra esistenza che è univocità per chi lo possiede.

and mappers for each class with higher level mappers using the child mappers to populate the arrays (either on request of the top level object or lazy load on request)

-Questo è dove vorrete espandervi un po '. Fondamentalmente, vorrai creare repository / factories che saranno in grado di recuperare e caricare le tue "entità" con i dati. Questo potrebbe essere ciò a cui ti riferisci come "Mapper", ma quando ascolto i mapper penso a " Active Record 's ". che sono oggetti che si salvano e si caricano e praticamente sono 1-1 con il database. Con questo concetto, scoppiare le "proprietà" fondamentali per intento può diventare disordinato (probabilmente funziona per alcuni).

Ecco alcune buone risorse che dovrebbero aiutare nel tuo sviluppo.

Dai un'occhiata a Domain Driven Design Concepts, ci sono alcuni Mogol là fuori che troverai molto rapidamente e ti offriranno una visione dettagliata delle teorie a portata di mano. Ecco alcuni link per iniziare:

questa è una spiegazione piuttosto breve: link

questo ha il nome di dominio interessante e si rivela essere un'ottima risorsa: link

    
risposta data 11.09.2012 - 19:42
fonte