Organizzazione di più codici di applicazione Zend

10

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

Senza entrare nei dettagli su cosa sia specificamente il progetto, sto cercando qualche input (visto che sto lavorando solo al progetto) su come ho "raggruppato" il mio codice. Ho provato a suddividerlo tutto in modo da rimuovere il più possibile le dipendenze.

Sto cercando di tenerlo disaccoppiato come logicamente posso, quindi tra 12 mesi quando il mio tempo è scaduto, chiunque altro entri non può avere problemi a estendere ciò che ho prodotto.

Struttura di esempio:

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 poiché non sono necessarie 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 da Zend-framework. Tutte le interfacce del modello e del mappatore non hanno riferimenti pubblici a Zend_Db, ma in realtà la racchiudono in privato.

Quindi la mia speranza è che in futuro potrò riscrivere i mapper e i dbtables (contenente un Models_DbTable_Abstract che estende Zend_Db_Table_Abstract) al fine di scindere la mia logica di business dal framework Zend se voglio spostare la mia logica di business (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 utilizzare versioni diverse dello stesso servizio in base alla richiesta e a quale applicazione si accede.

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

Lo stesso con le aplicazioni interne con Service_Auth_Internal che implementa service_auth_Interface Service_Locator :: getService ('Auth').

Sono preoccupato che possa mancare qualche possibile problema con questo.

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

Se qualcuno ha qualche suggerimento, sarei molto grato.

Ho usato contextswitching per le funzioni AJAX all'interno delle singole applicazioni, ma c'è una grande possibilità sia esterna che interna di ottenere servizi Web creati per loro. Di nuovo, questi saranno separati a causa dell'autorizzazione e dei diversi servizi disponibili.

\applicationstorage\Applications\internal\webservice 
\applicationstorage\Applications\external\webservice
    
posta user966936 15.10.2011 - 05:05
fonte

1 risposta

1

In definitiva alcuni codici saranno specifici per la "business logic" della tua applicazione, e alcuni sono "codici di libreria". Ad esempio, qualcosa che convalida l'input di un modulo può essere generalmente considerato come "libreria", mentre qualcosa che ti aiuta a calcolare le offerte disponibili per il cliente X in un dato mese sono chiaramente "business logic".

Questo è più un problema di controllo della versione, e ci sono molti modi in cui puoi skinare questo particolare gatto. Strumenti come Maven (e in parte 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 puoi mantenere repository separati per il codice library e importarlo nell'Applicazione X se ne hai bisogno.

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

    
risposta data 25.11.2011 - 23:06
fonte

Leggi altre domande sui tag