Controller anteriore in PHP

Question

Controller anteriore in PHP

#1 da (8 voti)
#2 da (1 voti)

5

Quando leggi lo sviluppo di applicazioni web, "front controller" e "single point of entry" sono parole frequenti con le quali ti trovi di fronte. A mio modo di vedere, il punto è fornire una singola posizione in cui decidi cosa fare nel tuo programma. Tutto sommato è bello e teorico, ma sono confuso su come questo sembrerebbe nella realtà.

In OOP, suppongo che il tuo "controller" venga comunemente istanziato in "index.php", o qualunque file sia il tuo "punto di ingresso". Ma come andare da lì e come appare la classe controller? È qualcosa del genere:

//Dummy-code, it's just to make a point
class Controller {

    //first function to be called
    public function main() {
        switch($appAction) {
            case "login": userLogin(); break;
            case "view" : viewArticle(); break;
            //...
        }
    }

    protected function userLogin() {
        //Sanitisation of user input
        //making instances of necessary classes etc.
    }

    //...
}

o ho completamente sbagliato l'intero concetto? Questa è l'unica cosa che posso immaginare di essere il caso, ma non sono sicuro se c'è un grave errore nell'avvicinarlo in questo modo o se ho appena frainteso lo scopo di un front controller.

object-oriented design php

posta Anpan 04.02.2014 - 10:32

fonte

2 risposte

1

Il front controller è solo un file PHP che dispaga le richieste, carica la configurazione, inizializza il meccanismo di caricamento automatico, ecc.

I quadri possono variare su ciò che accade nel front controller, ma di solito c'è un set di Route s, che mappa l'URL di richiesta a una coppia ( Controller , Action ). Ad esempio, se l'URL è user/login , è necessario richiamare UserController->loginAction() .

Come esempio di tale architettura, puoi leggere documenti di symfony .

risposta data 04.02.2014 - 11:40

fonte

Leggi altre domande sui tag object-oriented design php

Come gestisci il test del tuo software Android su dispositivi fisici? Il codice più grande è ancora più veloce

score 8 · Accepted Answer

PHP funziona come questo (perdona l'ovvietà, ma è una base importante da comprendere):

Visite client: esempio.com/about.php
Server (di solito Apache) riceve questa richiesta, controlla la struttura del file di dominio example.com e nella directory principale cerca "about.php". Se è presente il server esegue PHP con una destinazione di about.php.
PHP legge il file, eseguendo lo script come scritto.

Ora, cosa c'è di sbagliato in questo? Beh, per lo più niente. Ma alcune serie di lamentele hanno cominciato a essere comuni.

Uno, come si passano informazioni extra a uno script nell'URL? Beh, si cercano stringhe, naturalmente ... e alcune persone le hanno trovate brutte, e in tempi antichi selvaggi e lanosi ci sono state molte voci che gli URL con stringhe di query non sono stati correttamente accreditati - o addirittura indicizzati - dai motori di ricerca. Gasp!

Altre persone hanno trovato brutte e difficili da capire le stringhe di query. Ma che dire di internet non è amiright ?

Un'altra linea di problemi riguardava le "applicazioni web" e il modo in cui la maggior parte o anche tutte le pagine hanno la stessa logica di base in alto. Potresti voler elaborare alcune stringhe di query, o gestire i cookie, caricare qualche logica di template, ecc. E si pensava che fosse disordinato avere file tutto intorno, condizionali inclusi per mantenere gestibili le dimensioni dei file, e così via.

Nell'antichità, PHPophiles aveva solo un common require () di un file che conteneva tutta questa logica comune. Ma questa tecnica cadde in disgrazia molti anni più tardi (forse fino a 5 anni dopo se ci si può credere), come alcuni ritennero ripetitivo e antiquato (tra le altre cose).

Si è quindi reso noto che è possibile utilizzare Apache per indirizzare TUTTE le richieste a un singolo file, e fare in modo che Apache converta le informazioni extra sul percorso nell'URL e le passi come parametro in un semplice file index.php!

Questa idea di base, che tutte le richieste sono inviate a un singolo file invece che a singoli file PHP direttamente, divenne nota come "front controller".

Il mio framework preferito per scopi dimostrativi su come queste cose possono essere gestite è CodeIgniter , perché non è super magico o complesso. Dai un'occhiata a il loro file index.php per vedere come potrebbero funzionare le cose.

Fondamentalmente è solo un normale file PHP, che a sua volta definisce costanti che potrebbero tornare utili altrove, (come BASEPATH e simili), gestisce alcuni errori di sistema irrecuperabili (come l'intera cartella dell'applicazione che si trova in un posto sconosciuto!), ecc. Quindi, una volta terminato, il file successivo nell'applicazione viene caricato e in linea.

Con i controller frontali una funzione chiave consiste nel disconnettere la struttura del file di directory del sistema reale sul server dal percorso dell'URL. Dove come ai vecchi tempi se avevi una cartella nella directory principale chiamata "errata", e un file in quel nome "misc-gumballs.php", l'URL per arrivare a quel file era semplicemente "example.com/errata/ Varie-gumballs.php".

Con un front controller potresti invece scegliere "example.com/super-delicious-free-samples/gumballs", e usando Apache e PHP invece esegui un file index.php che appare in una cartella "predefinita" carica il file "classes.php" al suo interno, esegue la funzione all'interno della classe Page definita in quel file gumballs($param = null) e passa "super-delicious-free-samples" come valore del parametro.

Ack, Storia! TLDR;

Un front controller è solo un semplice file PHP che, usando qualcosa come le regole di routing Apache sul lato server, ha richieste di canalizzazione ad esso anziché a singoli file PHP direttamente. Ciò consente di inserire tutta la logica comune in quel file e di scegliere condizionatamente come procedere con la richiesta in base ai dati parametrizzati dal percorso di richiesta.

Può essere semplice come un include condizionale () o require (), oppure può creare un'istanza di un design complesso orientato agli oggetti. Non c'è davvero nulla di magico o anche particolarmente complesso su di loro.

Il tuo codice di esempio non è completamente fuori dal marchio, anche se è un po '"public void main" per la solita codifica in stile PHP. La maggior parte dei sistemi che ho visto implementano le funzioni come nomi di pagine, ma questo non è un requisito rigoroso e quindi non c'è nulla di sbagliato - concettualmente - con il tuo esempio!

Penso che ce l'abbiamo.