[PHP-MySql] Ottimizzare il codice utilizzando le classi?

[shake84]

Ciao a tutti,
In questi giorni sto cercando di ottimizzare il codice del mio sito e mi è stato detto che sarebbe meglio dividere queste 3 componenti:

INTERAZIONE CON IL DB <-> PHP <-> GRAFICA

Andando in ordine i miei dubbi/perplessità sono i seguenti:

INTERAZIONE CON IL DB - PHP

Per una questione anche di manutenzione del codice sorgente, sto cercando di dividere la parte in PHP che interagisce con il Db da quella che si occupa dell'elaborazione delle informazioni.

Per farlo avevo intenzione di raggruppare il tutto in una classe.

Es:

class GestioneDb{
  //Variabili globali della classe
  var $db; //Database
 
  function GestioneDb($host,$db,$name,$password){
    $this->db = mysql_connect ("$host", "$name", "$password") or die ("Errore");
    mysql_select_db ("$db");
  }

   function getOnline(){
 	return(mysql_query("SELECT * FROM online ORDER BY nome", $this->db));
  }

E così via aggiungendo una funzione per ogni tipo diverso di query, ottenendo così una classe di circa 600 righe di codice suddivise tra un centinaio di funzioni diverse.

Il mio dubbio è, in termini di prestazioni, considerando anche lo spreco di risorse (come cpu e memoria) è effettivemente vantaggioso utilizzare questo sistema, in cui per ogni pagina che visito, istanzio un oggetto di cui utilizzerò al massimo 2 o 3 funzioni su 100?

Esisiste un sistema migliore per realizzare la divisione dell'interazione con il db dal resto del codice?


PHP - GRAFICA

Veniamo ora al secondo punto, ovvero la divisione tra il codice PHP e la parte grafica (solo i codici HTML, per la parte dei CSS non c'è problema).
Per risolvere questo "problema", so che è possibile utilizzare script appositi come Smarty oppure costruirsene di propri in base alle esigenze.

Sempre parlando in termini di prestazioni e quindi tempi di risposta e carico sul server, mi chiedevo:
Se per un sito non ho grandi esigenze di cambiarne la grafica (ovvero una volta fatta rimarrà la stessa per anni).

E' effettivamente utile suddividere le cose, costringendo ogni volta PHP ad includere e rielaborare tutto?

[daniele_dll]

ho letto solo il titolo e li mi sono fermato

voglio solo dirti che le classi non servono a "ottimizzare" ... il codice ben scritto serve a ottimizzare ... la XP serve a ottimizzare ... gli "esperimenti" servono a ottimizzare

le classi no

le classi servono, al max, ad ottimizzare il tuo tempo perché se sono scritte con criterio e logica sono riusabili al 100% nel codice di altri tuoi progetti e quindi li ottimizzano, ovvero li risparmi tempo

[shake84]

Originariamente inviato da daniele_dll
le classi servono, al max, ad ottimizzare il tuo tempo perché se sono scritte con criterio e logica sono riusabili al 100% nel codice di altri tuoi progetti e quindi li ottimizzano, ovvero li risparmi tempo

Ehm.. si effettivamente ho utilizzato il termine in maniera imprecisa :master: ..

Tuttavia ti chiederei gentilmente di leggere il primo quesito del post, quello sull'utilizzo o meno di una classe nell'esempio che ho fatto..
Leggendo il forum, mi è parso di capire che sei uno di quelli che ne capisce parecchio, e sarei felice di avere un tuo parere..

[daniele_dll]

allora ciò che hai fatto è utile ma sbagliato

devi separare i vari strati l'uno dall'altro per ottenere qualcosa di funzionante e riusabile!

Ovvero

    Mysql    PGSql    SQLite
      |        |         |
      |        |         |
      |        |         |
      +--------+---------+
               |
               |
               |
              DAL
               |
               |
               |
   +-----------+------------+
   |           |            |
   |           |            |
   |           |            |
Gestione   Gestione     Gestione
Sessioni    Moduli    NonSoCheCosa

Questo è il modello che dovresti seguire per iniziare a ottenere dei risultati apprezzabili, ovvero separare la logica dei vari componenti per poi farli cooperare tra loro

DAL -> Database Abstraction Layer

In realtà è solo una classe che implementa le funzioni specifiche di un db ma le implementa in modo che cambiando funzioni i metodi che espone lavorino allo stesso modo fornendo portabilità del codice sorgente

Anche se quest'ultima cosa non ti serve veramente ti consiglio comunque di seguire questa linea di progettazione per poter sviluppare una classe per la gestione del database a basso livello (connessione, selezione db, elaborazione di query e funzioni personali ed altro ancora) strutturata correttamente

ti consiglio di leggerti della documentazione prima sullo sviluppo ad Oggetti, poi ti consiglio di leggere degli esempi di strutture di questo tipo, o framework, dato che si chiamano cosi, e per finire dai un'occhiata a dei documenti sulla XP con php (eXtreme Programming)

PS: dai un'occhio alla pillola che ho scritto sull'argomento framework/cms che può esserti utile

[shake84]

Innanzitutto grazie ancora per la risposta, ora ho letto per bene la tua pillola e mi sto informando anche su altre cose, tuttavia, ora ancor più di prima mi assale un dubbio..

Tratto dalla Pillola "Frameworks e CMS"

Originariamente inviato da daniele_dll
Perché ogni volta che il parser deve includere qualcosa deve:

1) Caricare il file in memoria
2) Validare il file dal punto di vista della sintassi
3) Trasformare tutto in byte code
4) Eseguire il Byte Code

Visto che la mia classe si trova su un file diverso (es. class.gestioneDb.php) di circa 600 righe di codice;
e visto che praticamente ogni pagina del mio sito interagisce con il db, ogni volta il server sarà costretto a un sacco di lavoro inutile, rallentando così il tempo di esecuzione di ogni pagina? :master:

:master: A questo punto mi sorge una domanda, per caso esiste già un qualche script o altro che:

-data in input una qualsiasi pagina PHP (che ne può includere altre);

-analizzi la pagina, controllando i vari script inclusi e per ogni oggetto dichiarato prenda solo i metodi effettivamente utilizzati;

-restituisca in output un qualcosa di già pronto all'esecuzione ad esempio in Byte Code, memorizzandolo in una data cartella che farà da cache.

Esempio pratico:

Avendo questi 4 file:

db.php //pagina che conterrà tutte le funzioni per interagire con il db;

grafica.php //pagina che conterrà tutte le funzioni per generare la grafica;

template.htm //pagina che conterrà le informazioni sulla grafica (html, javascript, altro);

pagina.php //pagina principale in cui vengono inclusi i file "db.php" e "grafica.php";

Do in pasto al mio ipotetico programma il file pagina.php, questo prende elabora un po' il tutto, prendendosi solo e soltanto quello che effettivamente viene usato in ogni file, e restituisce un file già pronto all'esecuzione.

Conclusioni, a discapito di un tempo iniziale N, più lungo del solito, che corrisponde all'assemblaggio del mio file, otterrei un vantaggio, credo non indifferente per le esecuzioni future...

[andr3a]

Originariamente inviato da daniele_dll
DAL -> Database Abstraction Layer

non è propriamente un layer astratto ma un'interfaccia astratta perchè il layer fa altro ma è un' insieme di classi dedicate che risultano portabili pur usando sempre la stessa sintassi ... si chiama PDO, introdotto in PHP5 e portato nel 4 dal sottoscritto

http://www.phpclasses.org/browse/package/2572.html

[daniele_dll]

Originariamente inviato da andr3a
non è propriamente un layer astratto ma un'interfaccia astratta perchè il layer fa altro ma è un' insieme di classi dedicate che risultano portabili pur usando sempre la stessa sintassi ... si chiama PDO, introdotto in PHP5 e portato nel 4 dal sottoscritto

http://www.phpclasses.org/browse/package/2572.html

No antré ... è un Layer d'Astrazione perché è uno strato che si interpone tra un set di database che espongono N funzionalità e propone M metodi per lavorare con le funzionalità comuni e Q metodi per lavorare con le funzionalità specifiche o tramite apposite estensioni alla struttura o tramite appositi metodi per lavorare con le funzioni proprietarie/non comuni

Layer -> perché è uno strato di codice che si interpone tra due componenti
Astratto -> perché "astrae" delle funzioni specifiche raggruppandole in altro funzioni per avere un'interfaccia specifica che permetta la gestione di tutto

ho appositamente usato la parola "interfaccia" perché un Layer Astratta è per sua natura un'interaccia, non potrebbe esporre funzionalità uguali per uno specifico set di funzioni se non fosse un'interfaccia

comunque tornando al discorso Database ... è meglio che ti fai la classe per 2 motivi:
1° - essendo la tua prima classe ti servirà a farti le ossa e dato che è un componente fondamentale usato ovunque è facile che avrai necessità di ristrutturarlo (ergo refactoring) ed è cosa buona
2° - capisci la logica che sta dietro a strutture come PDO et simili e ti permette sia di usarli meglio sia di sviluppare le tue strutture meglio

comunque preferisco sempre le soluzioni personalizzate, se ci sono bug si possono correggere

[andr3a]

Originariamente inviato da daniele_dll
No antré ... è un Layer d'Astrazione perché ...

non parlavo della tua risposta ma della mia, ovvero di PDO che non è un layer di astrazione, è un' interfaccia, che è diverso


http://it.php.net/manual/it/ref.pdo.php

PDO does not provide a database abstraction; it doesn't rewrite SQL or emulate missing features. You should use a full-blown abstraction layer if you need that facility.

per il discorso soluzioni personalizzate sono d'accordo, sempre che uno è in grado di farle, io in questo caso gli ho solo indicato una valida alternativa che
1 - è arrivato secondo nell' innovation award del sito più noto di classi PHP della rete
2 - non ha alcun bug report da quando è uscito (e qualora spuntasse vai tranquillo che risolverei "real-time", è alla base di tutti i miei lavori per PHP 4 o 5, non l'ho mica abbandonato )


quindi, se vuole farsi le ossa, che se le faccia a spese proprie, se vuole una delle tante possibili soluzioni, ecco il link (sempre quello)

[shake84]

Mhh.. credo che la discussione si sia spinta verso un punto, più specifico di quanto credessi, comunque sia ringrazio lo stesso, anche perchè probabilmente sarei tornato a chiedere tra qualche tempo
(prima di aver preso un'altra cantonata la classe sviluppata da Andr3a dovrebbe fare qualcosa tipo AdoDB, giusto?)

Rileggendo bene le vostre risposte però mi è sorto un atroce dubbio

Inizialmente nella classe che stavo cercando di sviluppare, stavo inserendo tutte, ma proprio tutte le interrogazioni al database, che venivano eseguite all'interno delle mie pagine (da qui l'elevato volume di funzioni, create poichè dentro la classe, ma non utilizzate).

In questo modo per ogni mia pagina, il database e l'SQL potevano anche non esistere, in quanto ogni interrogazione veniva fatta all'interno della classe.

Da quanto mi è parso di capire ora, il mio approcio è completamente sbagliato, in quanto dovrei lasciare le stringhe che contengono i comandi SQL nelle mie pagine ma far eseguire quei comandi tramite una classe a parte che sarà in grado di interfacciarsi con ogni tipo di DB (il "DAL" indicato da Daniele o attraverso il "PDO" indicato da Andrea)..

Ditemi voi perchè sono in crisi

[daniele_dll]

si, dovrebbe essere cosi per avere una maggiore separazione e anche una maggiore portabilità

il PDO di antrea è simile a AdoDB ma MOLTO più leggero oltre che completamente compatibile con PDO di php 5.1 di conseguenza usando php 5.1 trai il vantaggio della velocità di esecuzione dato che è un'estensione

inoltre ti sconsiglio anche di pensare di usare AdoDB perché è disunanimamente pesante!