applicazioni multi-tier con PHP?

Question

Sono relativamente nuovo a PHP, ma esperto programmatore Java in ambienti aziendali complessi con architettura SOA e le applicazioni multilivello. Lì, avremmo normalmente implementare applicazioni di business con la logica di business nel livello intermedio.

Sto programmando un sistema di moneta alternativa, che dovrebbe essere facile schierabili e personalizzabile da parte di individui e delle comunità; sarà open source. Ecco perché php / mysql sembra la scelta migliore per me.

Gli utenti dispongono di account, e ottengono un equilibrio. Inoltre, il sistema calcola i prezzi a seconda del totale dei servizi erogati e un totale attivo disponibili.

Questo significa, su un acquisto una serie di calcoli accadere; l'equilibrio ei totali vengono aggiornati; Queste cifre sono derivate, qualcosa normalmente non mettere in un database.

Tuttavia, ho fatto ricorso a mettere trigger e stored procedure nel db, in modo che nel codice php nessuno di questi aggiornamenti sono fatti.

Che cosa la gente pensa? che è un buon approccio? La mia esperienza mi suggerisce che questa non è la soluzione migliore, e mi spinge a implementare un livello intermedio. Tuttavia, non avrei nemmeno sapere come fare. D'altra parte, ciò che ho finora con negozi proc mi sembra la più appropriata.

Spero che ho fatto la mia domanda chiara. Tutti i commenti apprezzato. Non ci potrebbe essere una soluzione "perfetta".

Answer 1

Come è la tendenza in questi giorni, sempre lontano dal DB è generalmente una buona cosa. Si ottiene più facile il controllo di versione e si arriva a lavorare in una sola lingua. Più di questo, sento che le stored procedure sono un modo difficile andare. D'altra parte, se vi piace quella roba e ti trovi bene con SP in MySql, non sono male, ma la mia sensazione è sempre stata che sono più difficili da eseguire il debug e più difficile da gestire.

Sulla questione trigger, non sono sicuro se questo è necessario per la vostra applicazione. Dal momento che gli eventi che attivano i calcoli vengono richiamati dall'utente, queste cose possono accadere in PHP, anche se l'utente viene reindirizzato a una "attesa" pagina o un'altra pagina nel frattempo. Ovviamente, i veri fattori scatenanti possono essere fatte solo a livello di DB, ma si potrebbe usare un thread demone che esegue uno script PHP ogni X secondi ... Evitare a tutti i costi e cercare di ottenere l'evento per far scattare dal lato utente.

Tutto questo detto, ho voluto collegare la mia soluzione preferita per lo strato di accesso ai dati su PHP: Dottrina . Non è perfetto, ma PHP è quello che è, è abbastanza buono. Fa la maggior parte di ciò che si vuole, e si continua a lavorare con gli oggetti invece di procedure di database e così via.

Per quanto riguarda il titolo, più livelli sono, in PHP, assolutamente fattibile, ma bisogna fare loro e rispettarli. codice PHP può chiamare altro codice PHP, ed è ora (5.2+) ben OO e tutto il resto. Facciamo in modo di ignorare il fatto che un sacco di codice PHP vedrete in giro è una schifezza totale e non ha nemmeno uso di metodi, lasciate che i livelli da solo, e la modellazione OO decente. Tutto questo è possibile se si vuole farlo, tra cui fare la vostra propria (o utilizzando uno esistente) soluzione di MVC.

Answer 2

Un problema con spingendo un sacco di funzioni al livello DB, invece di un livello di astrazione dati, è che si ritrovano bloccati nella serie di funzioni del DBMS. Il software open source è spesso scritto in modo che possa essere utilizzato con diversi DB (certamente non sempre). E 'possibile che lungo la strada che si vuole rendere più facile porta per postgres o alcuni altri DBMS. Usando un sacco di caratteristiche specifiche di MySQL adesso farà quello più difficile.

Answer 3

Non c'è assolutamente niente di sbagliato con l'utilizzo di trigger e stored procedure e altre caratteristiche che vengono forniti dal server DB. Funziona e funziona bene, si sta utilizzando il pieno potenziale del DB, invece di relegandola ad essere un archivio di dati semplicistico.

Tuttavia, sono sicuro che per ogni sviluppatore qui che è d'accordo con voi (e me), ci sono almeno altrettanti che pensano l'esatto contrario e hanno avuto buone esperienze nel fare questo.

Answer 4

Grazie ragazzi.

Stavo usando db innesca perché ho pensato che potrebbe essere più facile da controllare l'integrità delle transazioni del genere. Come si può realizzare, Sono uno sviluppatore che è anche cercando di ottenere la presa della conoscenza db.

Ora, vedo che ci sia la soluzione di diffondere il codice PHP su più livelli, non solo logicamente, ma anche fisicamente la distribuzione su server diversi.

Tuttavia, in questa fase di sviluppo, penso che mi atterrò alla mia soluzione trigger / sp, come che non si sente a essere così sbagliato. Distribuzione su più livelli mi richiederebbe di ridisegnare la mia app in modo coerente.

Inoltre, pensando open source, se a qualcuno piace il sistema monetario alternativo, potrebbe essere più facile per le persone a cambiare solo il layout per le loro esigenze, mentre io non avrei bisogno di preoccuparsi che i calcoli ottenere sbagliato se le persone toccano codice PHP.

D'altra parte, naturalmente, sono d'accordo che roba db potrebbe ottenere molto difficile da eseguire il debug.

Gli script di init DB sono in controllo del codice sorgente, come lo sono i file PHP:)

Grazie ancora