Architetture di un DAM con framework MVC

Question

Architetture di un DAM con framework MVC

#1 da (1 voti)

2

Ho familiarità con OOP e PHP, ma sono nuovo per i framework MVC. Attualmente sto usando Laravel e l'ho trovato meraviglioso finora, ma le cose sono diventate più complicate man mano che progredisco, e ora capisco che ho bisogno di ripensare la mia architettura.

Il progetto è un gestore di risorse digitali per un piccolo cliente, ma voglio ancora assicurarmi che lo stia sviluppando meglio che posso, nonostante le sue dimensioni.

Le relazioni dell'oggetto di base sono:

UN PROGETTO può avere molte SEZIONI.
Una SEZIONE può avere molti ASSET.

Sembra abbastanza semplice, giusto?

Ho PROGETTO che funziona bene, usando REST, ma non sono sicuro di come trattare le SEZIONI e i BENI.

Ci sono 6 tipi di sezioni che un progetto può avere UNO di: es. Foto, collegamenti esterni, informazioni, video, ecc.

Alcune sezioni contengono una o più risorse. Ad esempio, una sezione Informazioni può contenere solo un corpo di testo, ma una sezione Foto potrebbe contenere molte foto. Ogni tipo di risorsa ha un diverso insieme di proprietà.

Idee per l'approccio

Se stavo scrivendo questo usando PHP vanilla, probabilmente avrei un oggetto Asset e quindi ho Photo, About, External Link, che Extended Asset.

Più ci ho pensato, più mi sono interrogato se ho anche bisogno di un oggetto Section.

Dato che sto usando MVC, non sono sicuro se dovrei avere un controller e un modello diverso per ogni tipo di risorsa, o se è eccessivo. Forse dovrei avere solo un modello di asset (e un controller di asset) e quindi avere più modelli per ciascuno dei tipi di risorse che estendono quel modello.

Sarebbe molto apprezzata qualsiasi assistenza per contribuire a modellare il mio pensiero verso un buon uso di MVC.

Aggiornamento: altri pensieri

Avendo avuto più tempo per riflettere, saperne di più su MVC e pensare ai commenti fatti da @RobertHarvey, ho iniziato a pensare di più ai Modelli che ho scelto. Vengo a pensare che è davvero dove si trova questa domanda (e la sua soluzione).

Ho iniziato a costruire il sito con un modello per ogni tipo di SECTION e tipo ASSET (ad esempio VideoSection e VideoAsset sono due modelli che ho ora.

Un progetto può avere una sessione video. Una VideoSection può avere molti VideoAssets. Le dita incrociate questo è un buon modo per avvicinarsi a questo.

architecture mvc laravel

posta Django Reinhardt 14.06.2017 - 13:27

fonte

1 risposta

Leggi altre domande sui tag architecture mvc laravel

Come testare un filtro Bloom? Git workflow e subtrees

score 1 · Answer 1

Questo è molto soggettivo e astratto, ma il seguente approccio mi ha aiutato in passato.

Quando mai mi vengono presentate sfide di progettazione come questa e sto usando un modello di progettazione in stile MVC. Trovo utile concentrarsi su 3 domande su come l'applicazione gestirà lo stato. Per me, le decisioni sulla gestione dei comportamenti in base allo stato dei miei dati tendono a collocare naturalmente le cose in posizione per la maggior parte del tempo.

1) Modello "cose":

Questa cosa ha uno stato? SE SÌ: considera la creazione di 1 o più oggetti modello per questa "cosa".

2) Controller "cose":

Mi interessa questo cambiamento di stato? SE SÌ: prendere in considerazione la creazione di un controller per gestire i comportamenti in risposta alla modifica dello stato di questa "cosa".

3) Visualizza "cose":

Devo mostrare lo stato di questa cosa? SE SÌ: considera la creazione di una o più viste per visualizzare lo stato corrente di questa "cosa".

Ovviamente questo è molto semplicistico, ma questo è il punto.

Puoi semplicemente continuare a fare le stesse domande mentre espandi la portata della tua applicazione e perfezionare i comportamenti che devi gestire.

Trovo anche utile mantenere alcuni limiti rigorosi per aiutare a mantenere le cose liberamente accoppiate e scopo singolo:

1) Gestisci solo le visualizzazioni tramite un controller.

2) Non associare oggetti modello alle viste.

3) Non associare oggetti modello ai controller, utilizzare invece un'interfaccia.

3) (Dati letti) Aggiorna solo i dati del modello da un livello di servizio.

4) (Scrittura dati) Se è necessario scrivere dati nel modello dall'input dell'utente e persistere, decidere un approccio coerente e attenersi ad esso.

5) Tutto deve comunicare, quindi decidere un approccio coerente e attenersi ad esso.

È tutto piuttosto soggettivo come ho detto e solo una visione delle cose. Non immagino che tutti saranno d'accordo con me, ma spero che questo ti aiuti a prendere delle decisioni.