Sviluppatore PHP alla ricerca di soluzioni equivalenti all'architettura Java EE

Question

Sono uno sviluppatore PHP, ho letto sulle tecnologie Java EE e voglio implementare tali tecnologie (n-tier, EJB, JPA ...) con PHP e tutto ciò che viene con (MySQL, Apache ...).

Answer 1

No.

PHP non è Java. Scrivere codice PHP come si scrive codice Java è sciocco e controproducente. È molto probabile che i futuri manutentori del codice vogliano farti del male.

È necessario mantenere un oggetto? Use an ORM.

Hai bisogno di un'architettura a più livelli? Se si progetta il codice con una corretta separazione delle preoccupazioni, hai già ottenuto 9/10th del modo in cui ci sono.

EJB? Ogni volta che leggo l'articolo di Wikipedia, sono descritti in modo diverso. Componenti riutilizzabili? Con un'interfaccia standardizzata per cosa, applicazioni distribuite e persistenza dei dati? Utile, si, ma non è PHP. Gli ORM e un a good message/work queue completeranno il lavoro.

La riga di fondo: Per la stragrande maggioranza degli script PHP, non avrete bisogno di alcuna "tecnologia aziendale". Se lo fai, stai facendo qualcosa di sbagliato: o hai sovradimensionato l'applicazione o hai scelto la piattaforma sbagliata.

Inizia a selezionare a modern PHP framework e crea la tua applicazione da lì. Se vieni da Java, Zend Framework sembrerà il meno straniero. Kohana, Symfony e CodeIgniter sono tutti meritevoli. Evita la torta per ora.

Rendilo semplice e non puoi sbagliare.

Answer 2

La tua domanda è perspicace. Questo perché quando la tua azienda avrà più successo, sarà necessario aumentare lo in scala per supportare il carico di più traffico. Quindi si dovrà separare il codice PHP in strati che girano su diversi livelli (sia server separati o macchine virtuali separate come con Xen.)

Per esempio, ho progettato un sistema scorso anno realizzato in PHP su 10 server Linux OpenSUSE che eseguono circa 25 macchine virtuali Xen (VM) Alcune delle macchine virtuali erano bilanciatori di carico, alcuni erano di fascia frontale, alcuni erano di livello intermedio e alcuni erano di tipo back-end, alcuni contenevano database MySQL e avevamo un paio di server dedicati che erano array RAID per l'archiviazione di file utente. Abbiamo creato montaggi NFS necessari per salvare/leggere i file da/verso l'array RAID.

Abbiamo raggruppato i livelli in tre gruppi correlati, in modo da poter disporre di siti di test indipendenti per QA, Staging (User Acceptance) e Production.

Così il nostro software PHP è stato separato in strati loosely-coupled come segue:

FRONT-END TIER (VM)

• Application Layer (porta 80) - comprese le risposte AJAX, validazione codice, navigazione, ecc.
• strato Admin (porta 443) - tra cui Admin Dashboard con accesso alle metriche di sistema e Unità test sfrutta
• Service Provider (porta 443) - Sicuro RESTful API dei servizi Web (con token) di fornire servizi ai partner e agli altri utenti che utilizzano il sistema come piattaforma " ". "

middle-tier (VM)

• Business Logic Strato - calcoli specifiche per il sistema o per affari, o i ruoli e le autorizzazioni per vari casi di utilizzo
• interoperabilità Strato - autorizzazioni e post a reti sociali o applicazioni Partner, ecc.

back-end TIER (VM)

strato

• Data Access - gestisce SQL query, inserimenti, aggiornamenti, elimina alla database (implementato come preparati dichiarazioni) in un modo che può essere adattato quando il database diventa un tipo diverso ... esempio: da PostgreSQL a MySQL o viceversa. Include codice PHP per il backup e ripristino dei database.

L'idea che un altro intervistato ha proposto di utilizzare un Framework per il software aziendale mi sembra piuttosto sciocco. Se stai sviluppando un progetto studente o una "prova di concetto" su un singolo server, e se hai già familiarità con un framework, potrebbe essere utile per la prototipazione rapida.

Tuttavia, come si vede da quanto sopra, quando si scrive codice di qualità di produzione, distribuito su più livelli, non è necessario utilizzare il framework.

Dove posizioneresti il ​​framework in tutti i punti del tuo codice? Ad ogni livello? Cattiva idea. I framework includono molte pagine che potrebbero essere necessarie e potrebbero non essere necessarie. Quindi rallentano le prestazioni, soprattutto se moltiplicate per ogni livello su cui è necessario installarle.

Altrettanto inefficiente sarebbe creare un "livello" solo per contenere un quadro che ogni altro livello dovrebbe chiamare. Il vantaggio dei livelli software è quello di essere liberamente accoppiati e indipendenti da altri livelli, in modo che quando le modifiche si verificano in un livello, non richiedono modifiche in un altro livello.

Inoltre, gli sviluppatori che scrivono il codice di qualità di produzione non devono fare affidamento su un "coltellino svizzero" che rappresentano i quadri. Tali sviluppatori sono in grado di scrivere codice mirato ed efficiente e, se necessario, riutilizzare le classi in una libreria che potrebbero aver sviluppato per progetti precedenti.