Visualizzazione dei risultati da 1 a 8 su 8
  1. #1
    Utente di HTML.it L'avatar di Reiuky
    Registrato dal
    Jul 2008
    Messaggi
    371

    [Zend framework] Una questione filosofica

    Premetto che sto ancora armeggiando con i tutorial di Zend e che sto cercando di venire a capo di alcuni problemi (per cui aprirò un 3d apposito).

    Però non riesco a entrare nella filosofia di zend, o meglio non riesco a capire bene il vcm (View Control Model)

    Premesso che sono pienamente d'accordo che un programma che legge da un db un dado e permette di modificarlo, cancellarlo, o inserirlo nuovo è troppo semplice per vedere le piene potenzialità di un VCM, e premesso anche che sono d'accordo che in un progetto grosso il VCM mi aiuterà a tirarci fuori comodamente le gambe, quello che non riesco a capire è come il VCM mi aiuta a rendere il codice più facile da mantenere.

    Mi spiego: per quello che ho visto, qualsiasi azione che debbo fare va a toccare 5 punti: uno è il controller, la action per intenderci. Poi ci sono due file che servono per l'accesso al database, uno è il modello della tabella e l'altro è quello che chiama il modello della tabella per fare la query. Infine due file per fare la view, di cui uno è il phtml che crea la schermata vera e propria e l'altro è il modello della form relativa alla phtml di cui sopra.

    Almeno questo è quello che ho capito dal tutorial. Se ho capito male, per favore, segnalatemi cosa mi è sfuggito.

    Quello che non capisco è come questa distinzione mi possa aiutare: significa che per ogni cosa che debbo fare devo verificare in almeno 5 punti diversi del codice (sparpagliati tra varie sottocartelle). Inoltre, almeno da quello che ho visto dal tutorial, non si tratta neanche di codice riciclabile: add ed edit sono praticamente identiche, con la differenza che add fa una insert sul db, edit fa una select e una update. Mi sarei aspettato un buon 90% di codice in comune, con la distinzione iniziale per sapere se deve o meno recuperare i dati precedenti e una finale per sapere se deve inserire o aggiornare. Invece, essendo due azioni distinte, hanno tutto il codice separato.

    Grazie in anticipo per le risposte.
    A volte penso che, nel darci l'intelletto, la natura sia stata più sadica che generosa.

  2. #2
    Il pattern MVC funziona così:

    - si riceve una richiesta
    - il front-controller verifica la richiesta e attiva il modulo che permette la gestione della richiesta
    - il controller del modulo convalida i dati e compone le viste
    - il mapper del modulo interagisce con il db se necessario
    - il model rappresenta la tabella con la quale interagire

    Quello che non capisco è come questa distinzione mi possa aiutare:
    Questa distinzione ti aiuta a gestire le richieste dell'utente niente di più, niente di meno..
    Una volta che capisci i 4 punti scritti sopra vedrai che sarà tutto più semplice.

    hai domande più specifiche altrimenti ci vuole un libro per risponderti
    Questa volta, più che un voto.. è favoreggiamento.

  3. #3
    Utente di HTML.it L'avatar di Reiuky
    Registrato dal
    Jul 2008
    Messaggi
    371
    Quote Originariamente inviata da Al_katraz984 Visualizza il messaggio
    Il pattern MVC funziona così:

    - si riceve una richiesta
    - il front-controller verifica la richiesta e attiva il modulo che permette la gestione della richiesta
    - il controller del modulo convalida i dati e compone le viste
    - il mapper del modulo interagisce con il db se necessario
    - il model rappresenta la tabella con la quale interagire



    Questa distinzione ti aiuta a gestire le richieste dell'utente niente di più, niente di meno..
    Una volta che capisci i 4 punti scritti sopra vedrai che sarà tutto più semplice.

    hai domande più specifiche altrimenti ci vuole un libro per risponderti
    Uhm... sto parlando parallelamente con un altro ragazzo che si occupa della cosa. Sì, è abbastanza evidente che debba fare un passo indietro e studiarmi la teoria dietro i VCM.

    Spero che internet mi venga incontro, per una volta.
    A volte penso che, nel darci l'intelletto, la natura sia stata più sadica che generosa.

  4. #4
    Utente di HTML.it L'avatar di Reiuky
    Registrato dal
    Jul 2008
    Messaggi
    371
    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)
    A volte penso che, nel darci l'intelletto, la natura sia stata più sadica che generosa.

  5. #5
    Quote Originariamente inviata da Reiuky Visualizza il messaggio
    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?
    Questa volta, più che un voto.. è favoreggiamento.

  6. #6
    Utente di HTML.it L'avatar di Reiuky
    Registrato dal
    Jul 2008
    Messaggi
    371
    Quote Originariamente inviata da Al_katraz984 Visualizza il messaggio
    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.
    A volte penso che, nel darci l'intelletto, la natura sia stata più sadica che generosa.

  7. #7
    Quote Originariamente inviata da Reiuky Visualizza il messaggio
    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:
    Codice PHP:
    // 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 __contructpdo $pdoview $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 __constructPDO $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 )
    Codice PHP:
    // 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.
    Questa volta, più che un voto.. è favoreggiamento.

  8. #8
    Utente di HTML.it L'avatar di Nikopol
    Registrato dal
    Jan 2011
    Messaggi
    120
    Solo una precisazione: design pattern della GoF tratta solo i design pattern (pattern orientati agli oggetti). Il front controller e il MVC sono pattern architetturali i quali agiscono a un livello più alto. Non sono trattati nel libro.
    La Guida Galattica è infallibile.
    È la realtà, spesso, ad essere inesatta.

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.