Evoluzione di un'applicazione: come gestire e migliorare il core engine?

Question

Evoluzione di un'applicazione: come gestire e migliorare il core engine?

#1 da (4 voti)
#2 da (2 voti)
#3 da (0 voti)
#4 da (0 voti)

2

L'applicazione web su cui lavoro è in diretta da un anno a questa parte, ma è tempo che si evolva e uno dei modi in cui si evolve è in un'applicazione multi-marca, in questo caso diverse aziende che utilizzano il applicazione, diversi modelli / contenuti e alcune lievi modifiche alla logica di business tra di loro.

Il problema che sto affrontando è l'implementazione di una procedura ottimale sul sito in cui vi sono differenze nella logica di business per ogni marchio. Questi saranno per lo più molto superficiali, utilizzando un provider di mailing list alternativo o acquisendo alcuni dati aggiuntivi in un modulo.

Non voglio avere se (brand === x) {...} else {...} in tutto il sito, specialmente perché la maggior parte di ciò che deve essere cambiato può essere gestita estendendo la classe esistente .

Ho pensato a diversi metodi che potrebbero essere usati per istanziare la classe corretta, ma non sono sicuro di quale sarà la migliore, specialmente perché alcuni sembrano portare alla duplicazione di più codice di quanto dovrebbe essere necessario.

Ecco cosa ho considerato:

1) Utilizza un caricatore statico simile a Zend_Loader che può richiedere la classe richiesta e conosce il marchio e può quindi restituire l'oggetto corretto.

$class = App_Loader::getObject('User', $brand);

2) Classi di fabbrica. Li utilizziamo già nell'applicazione per i prodotti, ma potremmo utilizzarli anche qui per fornire un'interfaccia trasparente alla classe.

3) Instradare la richiesta di pagina a un controller di marca specifico. Questo tuttavia sembra duplicare un sacco di codice / logica.

C'è uno schema o qualcos'altro che dovrei prendere in considerazione per risolvere questo problema?

4) Come gestire un progetto in crescita che ha più istanze personalizzate in produzione?

Aggiorna Questa è un'applicazione PHP, quindi le decisioni su quale classe caricare vengono fatte per richiesta. Potrebbero esserci oltre 100 diverse "marche" in esecuzione.

design-patterns software-evaluation

posta Phil Carter 26.06.2012 - 11:35

fonte

4 risposte

Leggi altre domande sui tag design-patterns software-evaluation

Dove risiede il mio schema di database in MVC? Progettare un grande database con più fonti

score 4 · Answer 1

In primo luogo, la mia esperienza con quello che un'altra azienda ha fatto prima: avevano esattamente lo stesso codice live utilizzato da molti dei loro clienti, con solo cambiamenti della pelle e molta logica condizionale alle spalle. Significa che se uno dei loro clienti è andato giù perché c'era un bug nel codice che è stato appena promosso, ognuno dei loro clienti è andato giù. Quindi tenetelo a mente. Vuoi avere distribuzioni separate (si potrebbe pensare che sia una cosa da buon senso)

Mi chiedo se la cosa più semplice da fare sia implementare i modelli di strategia ogni volta che devi fare qualcosa di diverso. Poi, man mano che il numero di strategie cresce, puoi consolidarle insieme in una classe, con sottoclassi per ogni marca diversa, che vengono inizializzate da una fabbrica.

score 2 · Answer 2

Vorrei memorizzare diverse opzioni di configurazione in un database e scrivere un'applicazione di configurazione.

In questo modo puoi caricare la configurazione con "marca". Qualsiasi nuova funzionalità che sia brand sepcific può essere configurata sui siti dei marchi futuri, senza modificare il codice.

if (brand=="x") è essenzialmente hard coding, evitalo, sarebbe meglio codificare qualcosa come if (configObject.IsFeatureSwitchedOn)

EDIT: stai pensando di avere un'istanza distribuita che esegue più marchi? Non farlo, sarà un incubo di manutenzione e scalabilità.

score 0 · Answer 3

Penso che uno dei tuoi primi due suggerimenti dovrebbe fare il trucco. La terza opzione si tradurrà in troppe duplicazioni che aumentano il rischio che i difetti di codice scivolino nel flusso di produzione.

Ad un livello più ampio, le prime due opzioni sono essenzialmente lo stesso percorso logico e la differenza è dove vengono eseguite. Tu e i tuoi colleghi siete nella posizione migliore per determinare i mezzi meno dirompenti per inserire la modifica.

Se non lo hai già fatto, avere un modulo di configurazione comune semplificherà alcune delle modifiche che stai suggerendo. Mi scuso in anticipo per aver suggerito l'ovvio, ma volevo assicurarmi che fosse portato.

Se non lo hai già fatto, mappa i vari casi d'uso che probabilmente vedrai. Ti fornirà un quadro su cui fare riferimento quando pensi ai casi di progettazione e test da generare. Come altri hanno sottolineato, un codice più comune significa un maggior rischio di disabilitare molti siti client da un bug. I test automatici di regressione / stabilità aiuteranno a mitigare tale rischio. Idem con gli ambienti dev / test / prod, ma suppongo che tu abbia già questo posto.

score 0 · Answer 4

La domanda è: come gestire un progetto in crescita che ha più istanze personalizzate e in produzione con alcune personalizzazioni nel progetto principale? La risposta è - attraverso custom configuration process build nel tuo progetto principale.

Ecco alcuni suggerimenti di configurazione da MSDN - Gestione delle opzioni di configurazione . Questo può essere usato come idea su come configurare il tuo cosiddetto progetto "multi-brand" .

Potresti anche aver bisogno di pianificare una strategia per l'implementazione di progetti personalizzati che condividono funzionalità di base: ecco un esempio per la piattaforma .NET che potrebbe essere utilizzata come idea. MSDN - Configurazione del progetto per la gestione della distribuzione