Pattern di progettazione per più società in AngularJS

Question

Pattern di progettazione per più società in AngularJS

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

1

Siamo sul punto di lanciare v3 del nostro prodotto interno. v2 è stato scritto completamente in AngularJS e V3 sarà lo stesso, ma scritto completamente in Typescript.

Abbiamo alcuni clienti che hanno esigenze molto specifiche per il prodotto e ciascuno ha una propria versione (ospitata sulla nostra piattaforma) e ha una propria implementazione. Ci sono parti comuni condivise che sono le stesse per tutti.

Al momento tutto è in una soluzione (Visual Studio) che preferiamo grazie alla facilità di manutenzione, ma ha creato un gran casino di mix di impostazioni, opzioni specifiche dell'azienda ecc. Ci sono un sacco di istruzioni if-else nei controller, nelle direttive e persino nelle viste (ancora, tutto angularJS) da accompagnare per più aziende.

Ora in V3 stiamo ripensando questa configurazione e vogliamo diventare più flessibili, ogni azienda avrà i suoi controller, direttive e viste, con la possibilità di condividere parti e utilizzare un livello di servizio / dati per gestire attività condivise comuni .

Ora sto pensando come posso renderlo gestibile? Al momento abbiamo 6 clienti, ma ci si aspetta che crescano con 10-15 ogni anno. Temo che finiremo di nuovo con una grande pila di file disseminati nel progetto che rende difficile la manutenzione e il test.

Voglio evitare questo e mantenere il progetto flessibile e gestibile.

Dovrei trovare un modo per dividere ogni azienda in soluzioni separate con i file Javascript / Typescript comuni per l'avvio e il routing delle app in un progetto comune? Forse hai una sola cartella per ogni azienda con controller, direttive e viste personalizzati, ma come si gestirà il routing?

Come ci avviciniamo alla gestione delle app aziendali con più aziende?

PS. La nostra applicazione web è angolare perché quasi tutto è lato client, ha la capacità di funzionare al 100% offline per lunghi periodi di tempo, il back-end non è importante per questo problema.

design-patterns angularjs typescript

posta YesMan85 12.02.2015 - 04:23

fonte

3 risposte

Leggi altre domande sui tag design-patterns angularjs typescript

Approcci graduali all'iniezione di dipendenza Scegliere il modello / l'architettura di progettazione giusti per uno scenario

score 1 · Answer 1

Se davvero, davvero, davvero necessitano di così tante funzionalità specifiche del cliente, che non consiglio affatto, dovresti rendere la tua applicazione altamente modulare. Ogni volta che è necessaria una modifica specifica del client, basta creare un nuovo modulo invece di aggiungere un pasticcio if-else ai moduli esistenti. Rendi questi moduli il più piccoli possibile e usa interfacce e pattern come dependency injection per cercare di mantenerlo organizzato. Carica la versione client di un modulo laddove possibile o ripristina il valore predefinito.

NewsModule/NewsModule.js
NewsModule/ArticleHeader/ArticleHeader.js
NewsModule/ArticleHeader/ArticleHeader.ClientA.js
NewsModule/ArticleHeader/ArticleHeader.ClientC.js

Un metodo alternativo potrebbe essere (e questo è solo un pensiero, non sono sicuro che potrebbe funzionare e potrebbe far arrabbiare gli dei) per creare un ramo per ogni cliente. Spingi sempre dal master (o dal dev o da qualsiasi altra cosa) al client e mai viceversa.

        / ClientA
master -- ClientB
        \ ClientC

Tieni presente che, qualunque soluzione tu scelga, questa soluzione non sarà mai facile da mantenere. Bugfix sarà un dolore. La consegna continua sarà un dolore. Il test sarà un dolore. Ecc.

score 0 · Answer 2

Oltre ai suggerimenti di cui sopra, potresti prendere in considerazione la possibilità di ridefinire le parti dell'applicazione che operano in modo condizionato in base al cliente a un livello più alto di astrazione.

Dato che stai usando Typescript, il polimorfismo semplice può aiutarti ad astrarre il lavoro da una semplice interfaccia. Quindi puoi consentire al cliente specifiche implementazioni concrete di implementare il lavoro effettivamente svolto.

link

score -1 · Answer 3

Forse può essere sensato inserire prima tutto in servizi e poi suddividere ciascuno degli elementi specifici dell'azienda nella propria applicazione. Se la memoria mi serve, puoi avere più applicazioni angolari su una singola pagina, quindi dovrebbe essere possibile impostare le cose per instradare ciascuno dei tuoi clienti nel posto giusto.

Suppongo che tu possa quindi configurare il tuo file grunt o gulp con una sorta di attività principale per gestire la creazione e l'esecuzione dei test per ciascun progetto.