Modello del modello di dati di estensibilità

2

Mi chiedevo come saresti in grado di mappare i seguenti criteri a modelli di progettazione comuni. Uso PHP 5.3 e MySQL 5.5 e ho il mio framework mvc per la mia azienda, ma alcune parti potrebbero essere migliori e qui ci sono i requisiti:

(Prendi il concetto di un catalogo dato che è la prima app ad essere interessata nel nostro pool di applicazioni)

I controllori (prodotti, clienti e carrello) gestiscono tutte informazioni diverse, vale a dire il proprio insieme di modelli. Ad esempio, il carrello creerà oggetti cestino in memoria, assegnerà prodotti ad esso, quantità, ecc. Quindi salverà il cestino nel database e proverà la logica di pagamento e salverà il pagamento associato al carrello.

Il mio problema è che la maggior parte delle volte i nostri clienti desiderano personalizzare i diversi oggetti come il client (aggiungere più campi di coordinate o campi descrittivi) o il prodotto (aggiungere proprietà personalizzate al prodotto). Se il mio controller fa sempre riferimento al prodotto della classe, ma voglio estenderlo per creare:

MyCompany_Models_Product
MyClient_Models_Product extends MyCompany_Models_Product

Come installerò il mio sistema per supportare l'estensione delle classi e cambiare le classi usate dai miei diversi moduli, controller, viste e altri modelli. Se ho hardcode MyCompany_Models_Product come nome della classe nel controller e in tutti gli altri oggetti, come potrei fare per creare un sistema sovrascrivibile.

C'è qualche motivo per cui posso sfruttare questo problema?

    
posta Mathieu Dumoulin 23.02.2012 - 17:58
fonte

2 risposte

2

Non farlo attraverso l'estensione. Hai già un senso per quello che può trasformarsi in un disastro. L'estensione in fase di compilazione può -molto- portare facilmente a questo tipo di esplosione di classe (non vuoi estendere il prodotto una sola volta per ogni combinazione di proprietà extra richieste dal cliente). Invece, usa la composizione runtime.

Alcune domande pertinenti:

Questi cambiamenti influenzeranno la logica, o sono sempre (o anche per lo più) solo proprietà aggiuntive? In tal caso, perché non creare una classe denominata ProductProperty con proprietà Key e Value? Crea i tuoi prodotti attraverso un factory che non solo può creare un'istanza della classe Product, ma può anche controllare il database per vedere quali campi aggiuntivi il client ha richiesto essere sul prodotto. Potrebbe essere necessario archiviarlo separatamente come metadati da qualche parte nel database. Per ogni campo aggiuntivo specificato dal cliente, è possibile creare un'istanza di un'altra proprietà del prodotto e archiviarla in un elenco interno dell'istanza del prodotto.

Potresti anche voler aggiungere alcuni metodi utili come Product.hasProperty, .getValue, etc, per rendere l'accesso - e forse anche iterativo - queste proprietà meno di una seccatura.

    
risposta data 23.02.2012 - 22:18
fonte
0

Ci ho pensato la scorsa notte prima di andare a dormire e mi piacerebbe il tuo input su questa soluzione:

Userei una specie di modello di fabbrica che non conosco come si chiama. Per impostazione predefinita, questo factory può essere chiamato:

MyCompany_Factories_Products

E potresti chiamare:

MyCompany_Factories_Products::setProductModel('MyClient_Models_Product');
MyCompany_Factories_Products::setProductFactory('MyClient_Models_Products');

E per impostazione predefinita chiamerebbe:

MyCompany_Factories_Products::setProductModel('MyCompany_Models_Product');
MyCompany_Factories_Products::setProductFactory('MyCompany_Models_Products');

quando registro il modulo nel sistema.

Quindi, chiamando getProductModel o getProductFactory, potrei estendere la mia intera logica. Ovviamente non posso estendere i controller o mi troverei ad affrontare problemi relativi all'istanziazione ma, tutto sommato, penso che sia un buon modello ...

Devi sapere se esiste un nome per questo modello ...

    
risposta data 24.02.2012 - 14:22
fonte

Leggi altre domande sui tag