Usare database Propel con PHP5 (Parte VII)

Pagina 7 di 8

Ulteriori strumenti

Per quanto scrivere un'applicazione per l'utilizzo di Propel possa essere molto più veloce rispetto al modo tradizionale, la configurazione del suo ambiente di programmazione e di attivazione richiede un po' di tempo. Una delle attività che richiede più tempo è la preparazione del file XML di descrizione dello schema del DB. Fortunatamente Propel rende possibile generare questo file sull'esempio del database esistente. Questo è particolarmente comodo se inseriamo Propel in un progetto in cui il database sia stato già precedentemente progettato.

La generazione del file XML è effettuata in modo simile alla generazione dei file classe, utilizziamo per questo compito(ingl. target) Phing di nome creole (maggiori informazioni nella Cornice Installazione). Un esempio di richiamo può essere: phing -Dproject=bookstore creole. Anche se, nel file ottenuto schema.xml dovremo sicuramente eseguire delle modifiche a mano, questo è più comodo che iniziare tutto il lavoro da zero.

Vale la pena di dedicare un po' di tempo ad approfondire la conoscenza delle altre direttive preparate dagli autori di Propel (l'elenco, insieme alle descrizioni, lo otteniamo dopo il richiamo di Phing con l'opzione -list). Tra queste troviamo ad esempio la possibilità di esportare i dati in formato (datadump), e in seguito di importarli nel DB prescelto (datasql). È questo un eccellente modo per migrare da una piattaforma di database, ad un'altra.

 

ORM – ne vale la pena

Osservare alcuni degli esempi di applicazione di Propel, ci da un'idea della quantità di tempo che grazie ad esso possiamo risparmiare in fase di scrittura di un'applicazione web che utilizzi un database. Inoltre, l'indipendenza dell'applicazione da un sistema specifico di database ci dà non solo la possibilità di far girare l'applicazione ad es. su MySQL, PostgreSQL e Oracle, ma anche ci mette al riparo, ad un certo livello, dagli spiacevoli effetti della modifica del nome della tabella e di quelli dei suoi campi. Purtroppo ci priveremo di queste possibilità se, nei nostri script, inseriremo istruzioni SQL caratteristiche del dialetto di uno specifico database.

Nonostante gli indiscutibili pregi che comporta l'utilizzo di una soluzione di tipo ORM, conviene riflettere sulle sue potenziali trappole. Prima di tutto dobbiamo ricordare, che l'utilizzo di strumenti di mapping si collega alla scrittura ed all'assistenza delle meta-informazioni. Nel caso di Propel queste assumono la forma di XML. D'altra parte, nell'accesso standard, tutte le meta-informazioni vengono distribuite dall'intera applicazione in istruzioni SQL. Esiste la possibilità che nonostante l'impegno di lavoro iniziale, l'utilizzo del supporto ORM risulti essere più facile nella manutenzione e nello sviluppo. Da tutto ciò discende una semplice conclusione, che Propel e le librerie simili, si confanno a progetti grandi, invece nel caso di quelli piccoli e di vita corta, possono costituire un'inutile complicazione.

Un altro argomento, spesso riportato contro le soluzioni di tipo ORM è il problema dell'efficienza. Nel caso di parti di query specifiche SQL, può accadere che, il codice generato automaticamente attraverso la mediazione dell'Abstraction Layer, sia meno efficace di quello scritto a mano dal programmatore. Risulta difficile fornire una ricetta univoca, perché l'efficenza di un programma dipende in larga misura dal modello fisico dei dati. Si può assumere, come regola generale, che gli strumenti ORM, si verificano meglio nel caso di pagine nelle quali compaiono molte query su un unico oggetto con diverse tabelle. Un buon esempio può essere il negozio on-line, dove, a parte le schede dei prodotti, vediamo i loro prezzi e recensioni, il nome dell'utente loggiato ed il contenuto del cestino, i santi del giorno, le categorie dei prodotti e le diverse novità. Occorre usare estrema prudenza nell'applicare ORM in applicazioni in cui manipoliamo oggettie dati tabellari come ad es. rapporti, assortimenti ecc. In questi casi un approccio standard è più naturale ed effettivo.

Indipendentemente dal tipo di applicazione, informazioni concrete sulla sua efficienza si possono ottenere soltanto dopo la sessione di profilo. La nostra intuizione spesso ci inganna e le strettoie si trovano in posti completamente diversi da quelli in cui ce le aspettavamo. Anche se nel programma alcune operazioni vanno eseguite velocemente, è meglio codificare in SQL solo questi casi specifici, scrivendo ad es. il settore del codice generato in modo standard invece di servirci di ORM.

<<< Precedente  -  Continua >>>

 



Ti potrebbe interessare anche

commenta la notizia

C'è 1 commento
Marcello
Ti è piaciuto l'articolo?