Organizzazione multipla del codice dell'applicazione Zend


10

Nell'ultimo anno ho lavorato su una serie di applicazioni tutte basate sul framework Zend e incentrate su una complessa logica aziendale a cui tutte le applicazioni devono avere accesso anche se non usano tutto (più facile che avere più cartelle di libreria per ciascuna applicazione in quanto sono tutti collegati tra loro con un centro comune).

Senza entrare nei dettagli su ciò che il progetto riguarda in particolare, sto cercando alcuni input (mentre sto lavorando sul progetto da solo) su come ho "raggruppato" il mio codice. Ho cercato di dividere tutto in modo tale da rimuovere il più possibile le dipendenze.

Sto cercando di mantenerlo il più possibile disaccoppiato logicamente, quindi in 12 mesi, quando il mio tempo è scaduto, chiunque arriverà non potrà avere problemi a estendere ciò che ho prodotto.

Esempio di struttura:

applicationStorage\ (contains all applications and associated data)
applicationStorage\Applications\ (contains the applications themselves)

applicationStorage\Applications\external\ (application grouping folder) (contains all external customer access applications)
applicationStorage\Applications\external\site\ (main external customer access application)
applicationStorage\Applications\external\site\Modules\ 
applicationStorage\Applications\external\site\Config\
applicationStorage\Applications\external\site\Layouts\
applicationStorage\Applications\external\site\ZendExtended\ (contains extended Zend classes specific to this application example: ZendExtended_Controller_Action extends zend_controller_Action )
applicationStorage\Applications\external\mobile\ (mobile external customer access application different workflow limited capabilities compared to full site version)

applicationStorage\Applications\internal\ (application grouping folder) (contains all internal company applications)
applicationStorage\Applications\internal\site\ (main internal application)
applicationStorage\Applications\internal\mobile\ (mobile access has different flow and limited abilities compared to main site version)

applicationStorage\Tests\ (contains PHP unit tests)

applicationStorage\Library\
applicationStorage\Library\Service\ (contains all business logic, services and servicelocator; these are completely decoupled from Zend framework and rely on models' interfaces)
applicationStorage\Library\Zend\ (Zend framework)
applicationStorage\Library\Models\ (doesn't know services but is linked to Zend framework for DB operations; contains model interfaces and model datamappers for all business objects; examples include Iorder/IorderMapper, Iworksheet/IWorksheetMapper, Icustomer/IcustomerMapper)

(Nota: le cartelle Modules, Config, Layouts e ZendExtended sono duplicate in ogni cartella dell'applicazione; ma le ho omesse in quanto non sono richieste per i miei scopi.)

Per la libreria questo contiene tutto il codice "universale". Il framework Zend è al centro di tutte le applicazioni, ma volevo che la mia logica aziendale fosse indipendente dal framework Zend. Tutte le interfacce di modello e mapper non hanno riferimenti pubblici a Zend_Db ma in realtà lo avvolgono in privato.

Quindi la mia speranza è che in futuro sarò in grado di riscrivere i mapper e i dbtables (contenenti un Models_DbTable_Abstract che estende Zend_Db_Table_Abstract) al fine di disaccoppiare la mia logica aziendale dal framework Zend se voglio spostare la mia logica aziendale (servizi) in un ambiente framework non-Zend (forse qualche altro framework PHP).

Utilizzando un ServiceLocator e registrando i servizi richiesti all'interno del bootstrap di ciascuna applicazione, posso usare versioni diverse dello stesso servizio a seconda della richiesta e dell'applicazione a cui si accede.

Esempio: tutte le applicazioni esterne avranno un service_auth_External implementando service_auth_Interface registrato.

Lo stesso vale per le applicazioni interne con Service_Auth_Internal implementando service_auth_Interface Service_Locator :: getService ('Auth').

Sono preoccupato che potrei perdere alcuni possibili problemi con questo.

Uno a cui sto pensando a metà è un file config.ini per tutti gli esterni, quindi un'applicazione config.ini separata che sovrascrive o aggiunge al config.ini esterno globale.

Se qualcuno ha qualche suggerimento sarei molto grato.

Ho usato la commutazione dei contesti per le funzioni AJAX all'interno delle singole applicazioni, ma c'è una grande possibilità che sia i servizi esterni che quelli interni possano creare servizi web per loro. Ancora una volta, questi saranno separati a causa dell'autorizzazione e dei diversi servizi disponibili.

\applicationstorage\Applications\internal\webservice 
\applicationstorage\Applications\external\webservice

Risposte:


1

Alla fine un po 'di codice sarà specifico per la "logica di business" della tua applicazione, e un po' è il "codice di libreria". Ad esempio, qualcosa che convalida l'input del modulo può essere generalmente considerato come "libreria", mentre qualcosa che ti aiuta a calcolare le offerte disponibili per il cliente X in un determinato mese sono chiaramente "logiche aziendali".

Questo è più un problema di controllo della versione e ci sono molti modi in cui puoi scuoiare questo particolare gatto. Strumenti come Maven (e in una certa misura Phing / Ant) sono costruiti per assemblare applicazioni da varie fonti disparate , basate su una sorta di file di configurazione esterno (generalmente XML). Ciò significa che è possibile mantenere repository separati per il codice della libreria e importarlo nell'applicazione X se necessario.

Se hai il controllo sul tuo host, allora potresti pensare di spostare le cose della libreria nel percorso di inclusione e mantenerlo come progetto separato a lungo termine.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.