Come vendere l'architettura DRY [duplicato]

Il motivo principale contro due applicazioni è che è molto probabile che tu debba implementare i diritti utente in ogni caso . Presumibilmente non hai intenzione di consentire ad un consulente di inserire note sugli studenti che non consiglia, o di eliminare informazioni importanti senza privilegio di uber-admin o di modificare informazioni su consulenti diversi da loro stessi? Una volta implementato questo meccanismo, estenderlo agli studenti dovrebbe essere semplice.

NB: Se i tuoi superiori immaginano che i consulenti accademici siano in qualche modo al di sopra dei comuni mortali in termini di non uso improprio dei privilegi, hanno ricevuto una sveglia.

Others on the team think that it should be two completely separate applications because of the complexity of modifying the views based on the authorization level of the user.

Davvero? non si rendono conto che devono comunque creare queste viste se hanno fatto 2 applicazioni separate? Quanto è difficile mettere entrambe le viste nella stessa applicazione e decidere quale mostrare in base a un flag!

Ora, ammettiamolo, questo non implementa completamente DRY ma è un ottimo inizio - puoi riutilizzare tutto il codice di back-end. Qui è dove si svolgerà la maggior parte del lavoro e quindi è qui che si concentrerà la maggior parte del tuo impegno. L'interfaccia utente è quasi un ripensamento in confronto.

Questo dovrebbe superare il problema delle "2 applicazioni" e una volta che iniziano a creare la stessa vista due volte nello stesso progetto, allora penso che inizieranno a considerare la duplicazione e inizieranno a pensare alle parti che possono essere combinati in un'unica vista ... e poi puoi dire "Te l'avevo detto" con convinzione e compiacimento: -)

Per inciso, le migliori applicazioni stanno scrivendo in un modo disaccoppiato come questo, il back-end fornisce un'API che il cliente consuma. Questo dovrebbe risolvere il problema della "complessità delle chiamate", in quanto progetterai il back-end per fornire i dati e la logica richiesti (si spera) prima di iniziare la codifica. Immagina di utilizzare i dati forniti da un servizio di terze parti su Internet: non devi dire loro quali dati fornire, ma chiami le loro API e utilizza ciò che ti danno.

Chiaramente quelli per la soluzione a 2 app potrebbero non avere esperienza. Immagina solo di aggiungere questo altro campo a due volte.

La maggior parte dei framework MVC consente di creare percorsi separati per utenti separati (si pensi a example.com/admin, example.com/student, example.com/professor).

Questo ovviamente crea viste separate, ma (importante!) puoi estrarre parti comuni (RoR le chiama partial, cakePHP le chiama elementi). Questo è un approccio ben stabilito

(non vuoi finire con se è nelle tue viste per determinare se mostrare o meno questa parte).

Ricorda che ciò aumenterà la complessità, ma non così tanto. In prospettiva ci sono anni di gestione di questa app. Pagherai di più quando manterrai due versioni di quasi le stesse app.

// Modifica: controlla anche la risposta di julia-hayward: link questo è un punto eccellente - lo voterei, ma non ho abbastanza punti per farlo.

Il vero problema in questo caso è la manutenibilità a lungo termine di due codebase separati rispetto a un singolo codebase. Convincere persone che non capiscono il problema richiede la persuasione. La tua scuola ha un dipartimento di informatica? Che ne dici di una scuola aziendale o di un dipartimento di gestione? Un supporto interno da un istruttore sarebbe buono.

In breve, il problema è questo: scrivere due applicazioni, si finisce con due codebase, il che significa potenzialmente due volte tanto sforzo da mantenere fino a quando queste applicazioni sono in uso. La condivisione di moduli tra codebase può migliorare questo problema in una certa misura, ma se si sta andando così lontano con il ri-factoring dell'applicazione esistente, basta ridimensionare / re-architettarlo in una singola applicazione.

I manager respingeranno quello che vedranno come uno sforzo extra senza alcun guadagno funzionale, e devi convincerli che il payoff arriverà a lungo termine. Spetta anche al team tecnico fare un buon lavoro sull'applicazione per convalidare l'argomento che stai facendo, quindi se decidi di spingere per la soluzione che desideri, assicurati che il team possa eseguirne il backup.

Potrebbe esserci merito all'argomento secondo cui sarà complicato modificare l'applicazione esistente per adattarsi a diversi set di autorizzazioni, ma la complessità discussa è un problema che avrebbe dovuto essere affrontato prima che fosse creata la prima applicazione. Se l'esigenza di fornire la funzionalità agli studenti era nota in anticipo, è stato un errore non progettare per questo. Non lasciare che un errore passato impedisca alla squadra di prendere la decisione giusta per la fase successiva del progetto.

Penso di averne un'altra.

• L'applicazione del corpo docente e del personale funziona ed è in uso.
• Cambiarlo per creare un'applicazione per studenti ha un grosso rischio.
• Mi aspetto che ci siano pochi test del sistema automatico per l'applicazione del corpo docente e dello staff.
• Probabilmente gireranno su server diversi, in modo che l'applicazione dello studente non rallenti l'applicazione dello staff.
• Potrebbero avere cicli di rilascio e test diversi.
• Prima o poi il layout e l'interfaccia utente dovranno essere diversi tra le due applicazioni.

È possibile condividere il codice tra le applicazioni senza dover mettere tutto in una sola applicazione.

(Alcuni sistemi di controllo delle versioni consentono a ciascuna applicazione di avere versioni diverse del codice condiviso pur consentendo di rimanere sani di mente.)

Tuttavia, inizierei inserendo il codice condiviso in una libreria comune e creando sottoclassi per ogni app secondo necessità. Dovrà essere utilizzato un sistema di iniezione delle dipendenze, quindi un'applicazione può controllare la navigazione tra le viste con la necessità di avere tutte le viste a conoscenza di entrambe le applicazioni.

putting together a new MVC application

Some of the problems I am seeing with making this a separate application are:

MANY of the views would actually be the same data being displayed.   

Un argomento in favo (u) r di una singola app.

Both the HTML and model code would have to be copied between the solutions - not to mention the unit tests. I don't want to maintain the same code in both places which will eventually become very difficult to maintain. Won't the model code be identical, which two views and one or two controllers?

The skins for both sites are the same - any changes would have to be done in both places. 

CSS? In alternativa, puoi utilizzare AngularJs con i modelli per le tue visualizzazioni.

The authentication and authorization parts are exactly the same for both applications.  

We are authenticating against AD and have a common authorization database.

Ovviamente, se quel codice offre un'API pulita, può essere utilizzato indipendentemente dal fatto che tu abbia una o due app.

Personalmente mi piacciono gli AngulrJ per questo, perché ti consente così facilmente di mostrare / nascondere parti di una pagina web basandosi su un singolo dato nel $ scope del tuo controllore.

<div ng-hide="isStudent" class="ng-hide">
   staff specific HTML goes here ...
</div>

e, nel controller, basta impostare $scope.isStudent come appropriato.

Quindi, il mio voto è per una singola app e AngularJs

Dovresti essere esplicito quando parli con il tuo team che questo è un compromesso tra il time-to-market iniziale di una prima versione del sito dello studente e il costo totale di proprietà per tutta la durata del sistema.

Ho visto un vero sistema che si è evoluto in oltre un decennio basato su PHP, dove i clienti hanno un micro-sito extranet dove possono caricare / scaricare dati / report su un sistema back-end. Hanno iniziato senza il controllo del codice sorgente e hanno letteralmente copiato in una cartella l'ultimo micro-sito personalizzato per avviare il micro-sito del cliente successivo e apportato miglioramenti solo all'ultimo sito su cui stavano lavorando.

Un decennio dopo hanno avuto centinaia di micro-siti semi-personalizzati su diverse versioni del loro codice. Sorprendentemente il sistema era (ed è ancora) riuscito. Questo perché ogni micro-sito era "abbastanza buono" da consentire al client di fare il proprio inserimento di dati che era stabile per anni. Il fatto che ogni micro-sito avesse modifiche per cliente è stato persino trasformato in un punto vendita come "impegno cliente su misura".

Il punto chiave era che non hanno mai dovuto tornare indietro a testare i vecchi micro-siti quando hanno cambiato qualcosa su cui si stava lavorando per il nuovo client più recente. Il fatto che potessero fornire un'esperienza incoerente su tutti i client significava che non dovevano mantenere alcun codice comune (solo alcune comuni logiche di importazione / esportazione dei dati ai sistemi back-end che alla fine riuscivano a generalizzare come codice back-end altamente configurabile con un flat interfaccia file).

Fornisco questo esempio in quanto vi è sempre un'eccezione che dimostra la regola generale; la maggior parte del sito deve davvero offrire un'esperienza coerente, "ultima e migliore" a tutti gli utenti e non sarebbe razionale né accettabile lavorare nel modo appena descritto.

Con la tua applicazione se hai un sacco di logica codificata nella pagina, senza un motore allettante adeguato, nessun livello aziendale separato e livelli di accesso ai dati, e nessun modello di modello / oggetto dati isolato, senza test automatici di backend e nessun automatismo test front-end, quindi sì, i tuoi colleghi sono corretti, che lasciando ciò che viene fatto da solo e iniziando con una copia, che può evolversi rapidamente, parlando per lo più con le stesse tabelle di database, senza tornare a correggere e testare il sito esistente, otterrebbe un primo prototipo funzionante attivo e funzionante molto più velocemente di "farlo correttamente".

Tuttavia, dopo un rapido successo, il tuo datore di lavoro vorrà sfruttare la nuova applicazione per implementare nuove funzionalità e funzionalità che migliorano l'impegno tra il personale e gli studenti. Si aspetteranno che sia "una cosa sola" e coerente e apparentemente non "due cose" che lavorano duramente per rimanere sincronizzati.

Quello che devi elaborare è qual è il potenziale guadagno a lungo termine quando "lo fai correttamente"; quali sono le nuove caratteristiche comuni del futuro del sito che giustificano un modello di dati condiviso, una logica aziendale comune condivisa, modelli per tipo utente / viste condizionali utente sul modello / logica. Se tali requisiti futuri esistono (cosa che sicuramente devono), allora sarebbe chiaro che l'aggiornamento a un framework / cms / motore standard di sicurezza, inserendo un motore di template condizionale standard per il rendering delle viste, progettando / migliorando un dato condiviso modello, progettando una logica di business comune per tutti gli utenti, otterrebbe l'esperienza completa dello stato finale senza il doppio del codice e sicuramente il doppio dello sforzo e dei bug.

Raccomanderei di organizzare una revisione dei potenziali requisiti futuri e suggerire di intraprendere qualche lavoro di proof-of-concept (alcune settimane) nel trovare l'approccio migliore per preparare al meglio il sistema per soddisfare quei requisiti futuri mentre costruendo la fase successiva del progetto (ovvero framework di aggiornamento / migrazione delle funzionalità in un opensource cms è possibile scrivere moduli personalizzati per creare tutte le funzionalità su misura sfruttando la maturità del framework e il modello utente). Sospetto che al momento le persone si concentreranno sulla "scadenza imminente per far vivere il sito studentesco" e pensano a "non fare molte rilavorazioni o dover imparare qualcosa di nuovo". Pertanto, è necessario che il cliente / il capo siano entusiasti della futura funzionalità di destinazione / stato finale e che i tuoi compagni di squadra siano entusiasti di "farlo correttamente" con nuovi strumenti e nuove tecniche entusiasmanti. Quindi fare la cosa giusta si spera che diventi un'idea di tutti. In bocca al lupo.