[Zend framework] Una questione filosofica

[Reiuky]

Ok. trovato un libro di teoria. Design pattern di gang of four. Ne ho sentito parlare. Spero di venirne a capo (inutile dire che la versione italiana me la sogno stanotte)

[Al_katraz984]

Ok. trovato un libro di teoria. Design pattern di gang of four. Ne ho sentito parlare. Spero di venirne a capo (inutile dire che la versione italiana me la sogno stanotte)

ma cos'è che non capisci?

[Reiuky]

ma cos'è che non capisci?

Eh... non capisco la logica che ci sta dietro. Per me è solo una "inutile complicazione" come ho scritto nel tread sulle discussioni off-topic.

Inutile complicazione perché a me pare che questo modo di archiviare le cose serva solo ad aumentare i punti in cui bisogna andare a cercare il punto dove modificare / inserire / correggere le funzioni, senza darmi neanche la garanzia che un elemento X si trovi nel punto Y.

Però tu mi dici che è il contrario: che questa complicazione serve per dire "devi fare X, vai a cercare in Y il file che si chiama X+qualcosa e fai la modifica che ti serve" (almeno da quello che ho capito) e io oltre a fidarmi della tua parola non posso fare perché non ho capito come vengo vincolato a mettere in X+qualcosa X, né ho capito con quale logica X viene messo in Y.

In altre parole, mi sono reso conto di non capire la logica che c'è dietro al VCM. Non è una cosa nata su questo tread: mi sono confrontato anche con altri che lo conoscono ed è venuto fuori che mi mancano proprio le basi. Per questo ho detto "faccio un passo indietro e mi studio un po' di design pattern, sperando che la cosa mi aiuti"

Sicuramente male non mi fa.

Poi se non capisco neanche dopo aver studiato design pattern... Oh, posso sempre provare a fare la pizza. Magari mi riesce meglio.

[Al_katraz984]

Poi se non capisco neanche dopo aver studiato design pattern... Oh, posso sempre provare a fare la pizza. Magari mi riesce meglio.

Beh, se parti già così ti complichi la strada da solo...

Comunque, schematizzo e spero che si capisca

Design patter -> procedura testata e ritestata e ri testata da millemila persone che hanno verificato per certo che sia la procedura più semplice ed efficente per risolvere un problema.

FrontController è un design pattern
MVC è un design pattern

Per me è solo una "inutile complicazione" come ho scritto nel tread sulle discussioni off-topic.

essendo MVC e FC due design patterns questa frase che dici non può essere vera...


FrontController - viene utilizzato per ricevere gli input dell'utente e smistarli ai relativi moduli
MVC - serve a standardizzare la creazione dei moduli ed è strettamente legato al FC.


Il processo standard per gestire una richiesta dell'utente sarà:

a) utente richiede una risorsa
b) sistema riceve la richiesta e la passa al modulo designato (FC)
c) il controller effettua il controllo della richiesta (C)
d) se ci sono calcoli da effettuare o dati da recuperare dal db vengono fatti (M)
e) nel controller vengono composte le viste e "agganciate" alla vista principale (V)
f) sistema mostra l'intera vista

i punti c, d ed e vengono effettuati all'interno del controller.


In pratica:

l'utente richiede una risorsa, la risorsa si trova su: http://www.sito.it/index.php/modulo/azione/parametro
es. utente vuole vedere una pagina del sito: http://www.sito.it/index.php/pages/view/15

dove
http://www.sito.it - è l'host
index.php - è la pagina centralizzata per gestire le richieste (FC)
pages - è il modulo che gestisce le pagine all'interno del sito (formato da pagesController, pagesMapper, pagesModel e le viste)
view - è l'azione che l'utente ha richiesto
15 - identifica quale contenuto usare

tralasciamo la parte di frontController:

// controller
class pagesController {

  // essendo il controller il punto di incontro di tutto il modulo deve ricevere
  // da un livello più alto (che è index.php) alcune classi per operare
  // di solito:
  // il database e la vista globale
  public function __contruct( pdo $pdo, view $view ) {
    $this->view = $view;

    // nel costruttore carichiamo anche le classi utili per questo modulo
    // per interagire con il db ci serve il mapper
    // ed ecco che usiamo il db
    $this->mapper = new pagesMapper( $pdo );
  }

  // vogliamo permettere all'utente di vedere alcune pagine del sito
  public function view( $id_pagina ) {
    // prima cosa: il controller verifica i dati ricevuti, la faccio semplice
    // ma i controlli non sono mai abbastanza
    if ( !empty( $id_pagina ) ) {
      // i dati passati sono a posto, posso caricare i dati della pagina
      $page = $this->mapper->fetch( $id_pagina );

      // utilizzo i dati per popolare la vista della pagina
      $pages = new view( 'pages' );
      $pages->page = $page;

      // assegno un titolo alla pagina globale
      $this->view->title = 'Pagina di prova';
      // attacco la vista specifica alla vista globale
      $this->view->addView( 'content', $pages );
    }
  }


}


// il mapper serve per interagire con il db
class pagesMapper {

  private $pdo;
  private $table = 'pages';

  // un mapper ha sempre bisogno di un db per operare
  public function __construct( PDO $pdo ) {
    $this->pdo = $pdo;
  }

  public function fetch( $id ) {
    $query = "SELECT * FROM $this->pages WHERE id = :id";

    // la faccio semplice
    return $this->pdo->execute( $query, array( ':id'=>$id ) );
  }
} 

adesso che abbiamo tutto possiamo far partire l'esempio:

index.php (il livello più alto di tutti )

// carico il database
$pdo = new PDO();
// carico la vista globale
$mainView = new view( 'template' );

// su questo livello devo gestire le richieste dell'utente ed indirizzarle nel modulo corretto
// mi serve il frontController per centralizzare tutto sulla index.php
$fc = new frontController();

// passo il db e la vista globale che serviranno per i moduli
$fc->run( $pdo, $mainView );

// il frontController ha richiamato il modulo che ha attivato l'azione che ha popolato
// la vista globale con i dati richiesti e alla fine li mostra all'utente
echo $mainView->render(); 

spero possa esserti d'aiuto, se hai dubbi sempre qui sto.