Tutte le richieste PHP dovrebbero essere centralizzate?

2

In un sito Web multiuso (sistema utente, molte operazioni di database su tabelle diverse, programmi di creazione, ...) tutte le richieste PHP devono essere centralizzate su un'unica app?

Ad esempio, la configurazione corrente è la seguente:

  1. Le richieste relative all'utente vanno a users.php
  2. Gestire una tabella MySQL specifica va a ../tables/thatTableName.php
  3. Gestire un programma va a schedule.php
  4. ecc.

Ciascuno di questi file ha il proprio modo di elaborare le richieste in entrata ( $_POST e $_GET ).

Un altro approccio consiste nel centralizzare questo in qualcosa come un main.php che elabora tutte le richieste, crea le classi necessarie quando richiesto (come un utente) e coordina tutte le attività.

Quali sono i vantaggi e gli svantaggi di entrambi gli approcci?

    
posta user2410532 30.03.2016 - 04:25
fonte

3 risposte

3

La maggior parte delle principali applicazioni PHP che sono state create, diciamo, negli ultimi 10 anni utilizzano un modo di Front Controller per gestire tutte le richieste. Cioè, le richieste vengono instradate attraverso un singolo gestore che risponde (di solito seguendo alcune variazioni di un pattern MVC).

Per creare URL di facile utilizzo, come "/ utente", i reindirizzamenti sono impostati nel file .htaccess del sito o direttamente nella configurazione del server. Questi mappano il percorso richiesto all'insieme corretto di parametri per il Front Controller.

Che sia "migliore" o meno ... questo dipende solo da te. Ma il concetto di "una pagina = un file PHP" e l'utilizzo di intestazioni incluse () per gestire le funzionalità comuni è decisamente PHP vecchia scuola, e non qualcosa che seguono gli sviluppatori più moderni.

    
risposta data 30.03.2016 - 05:56
fonte
2

In un'applicazione di confronto www assicurati che tutto vada per la porta.

Se stai costruendo un single application dovresti avere un punto di immissione single . Se stai costruendo una serie di utili utility che sono accessibili tramite Apache o qualche altro app server, allora crea il gruppo di utility come singoli script ...

La cosa divertente è che una volta che hai diverse utility, qualcosa di comune emerge e diventa rapidamente un'app, cioè devo consentire queste parti a OPS e queste parti a qualcun altro, ad esempio Basic Auth e da lì a palle di neve in piena regola App o peggio un CMS .

    
risposta data 30.03.2016 - 08:48
fonte
2

Il vantaggio di avere un file diverso per endpoint è la semplicità durante la programmazione iniziale. Il lato negativo di tale approccio, rispetto a un controller anteriore, è la complessità pur mantenendo.

Ciascuno di questi file dovrà analizzare il suo input, eseguire i controlli CSRF e generare output. Questo codice è duplicato decine, centinaia, possibili migliaia di volte. Il codice duplicato è difficile da mantenere, poiché ogni modifica richiede la modifica di molti file. A peggiorare le cose, questo è quasi impossibile da testare o riutilizzare in contesti diversi, perché la logica all'interno dei file è direttamente legata all'input e all'output HTTP. Inoltre, se decidi di dover eseguire un refactoring approfondito, anche tutti gli URL cambiano, poiché non esiste alcuna separazione tra la struttura della business logic e il layout dello spazio URL.

Al contrario, un front controller può isolare la logica di business (nei metodi del controllore) dalla meccanica di input parsing e output building. Permette un posto centrale per gestire la logica comune come la gestione delle sessioni e i controlli CSRF. Permette inoltre di disaccoppiare l'URL dalla logica aziendale, consentendo un profondo refactoring senza modifiche visibili all'utente. L'unità che verifica la logica di business isolata diventa molto più facile, oltre al riutilizzo in altri contesti (ad esempio, nelle code di lavoro in background). Ci sono pochissimi aspetti negativi. Il codice diventa un po 'più difficile da capire fino a quando non scopri come gli URL sono mappati alla logica aziendale (che sarà un modo standard per quel framework), e il livello aggiunto di astrazione può avere alcune conseguenze minori sulle prestazioni.

I forti vantaggi di un front controller rispetto all'approccio one-file-per-end-point è il motivo per cui tutti i framework moderni utilizzano questo approccio.

    
risposta data 30.03.2016 - 09:23
fonte

Leggi altre domande sui tag