Ho letto e studiato i modelli di progettazione MVC, HMVC, MVP, MVVM e PAC quando sono venuto a conoscenza di questo articolo di larry garfield > MVC vs PAC
La mia implementazione:
Pensa a un'app modulare scritta in PHP, in cui tutti i moduli condividono gli stessi modelli / astrazioni ma hanno i propri controllori e viste.
I controllori possono creare richieste secondarie ad altri controllori e la risposta da queste sub-richieste viene quindi inclusa nella risposta primaria. Simlar to HMVC, ma per l'architettura è "non necessario" che ogni sottomodulo abbia la propria directory e sottodirectory che contengono i propri controller e viste
Anche le viste non sono le proprie classi di per sé ma invece le viste sono file template renderizzati (usando un motore di template) con un metodo con in controller. Alcuni potrebbero suggerire la sua più vicina a MVVM a questo punto, ma non è per il motivo che non è MVC / MVP, ma è estremamente vicino alla definizione di PAC di larry Garfield.
dopo tutte le mie ricerche sono incline a chiamarlo schema di progettazione basato su PAC, ma sono confuso nella struttura gerarchica dei modelli di progettazione PAC, la mia implementazione corrisponde alla gerarchia PAC o sarà piuttosto considerata come triade singola (a condizione che sia di fatto Basato su PAC e non ho torto). Anche secondo wikipedia:
The agents (or triads) communicate with each other only through the control part of each triad. It also differs from MVC in that within each triad, it completely insulates the presentation (view in MVC) and the abstraction (model in MVC).
Che cosa significa?
- Significa che nei progetti PAC, un traid / modulo nel modello di progettazione PAC non può accedere a modelli / astrazioni di altri traid / moduli?
- Oppure, vuol dire che a differenza di MVC, nei modelli PAC e nelle viste non si conoscono l'un l'altro.