Creazione di un business case per un'applicazione Silverlight a prova di futuro [chiusa]

0

Recentemente ho iniziato a lavorare per una banca piuttosto grande scrivendo app interne. Sono subappaltato dalla società per cui lavoro (a cui ho anche recentemente lavorato).

Questa banca ha recentemente aggiornato a Windows XP, in precedenza utilizzava Windows 2000.

Mi è stato assegnato il compito di riscrivere un'applicazione di visualizzazione dei report, che attualmente sto eseguendo in MVC4 (Windows XP == Visual Studio 2010). L'app originale è stata scritta in .net 2 con webfoms ed è un po 'caotica.

L'intera applicazione sembra fare affidamento sullo stato, in cui MVC si basa sull'abbraccio della natura stateless del Web, come nei dati immessi per formare A, influisce sulle opzioni visualizzate nel modulo B, le opzioni selezionate nel modulo B influisce sulla forma C ecc ecc (adoro MVC e penso che sia una cosa fantastica nel giusto contesto).

Gli interi modelli di mantenimento tra gli stati stanno diventando piuttosto disordinati, e non posso fare a meno di pensare che sto sbagliando o non usando lo strumento giusto per il lavoro.

I miei pensieri sono che WPF sarebbe perfetto per questo, ma i computer sono controllati da un'agenzia esterna e sono piuttosto bloccati. Abbiamo un po 'più di controllo sui server che ospitano le applicazioni. L'ovvia opzione successiva è Silverlight (penso, forse sono terribilmente sbagliato!)

Un paio di domande.

Primo: MVC ASP è effettivamente l'opzione migliore qui o sto sbagliando?

Secondo: quale argomento presenteresti alla direzione se tu fossi d'accordo con me e pensassi che un'applicazione basata su Silverlight fosse la strada da percorrere?

L'utilizzo di tecnologie non basate su MS è un no. MVC4 è controverso.

    
posta Throwaway 24.09.2013 - 20:29
fonte

2 risposte

6

Prima di tutto, non esiste un'applicazione "a prova di futuro". Semplicemente non esiste. Un'applicazione può essere progettata per gestire il cambiamento più facilmente e quindi adattarsi meglio al futuro, ma non è a prova di futuro.

Dato che sei in un punto di decisione tecnologico e sei vincolato allo stack Microsoft, questo è il mio consiglio basato sulla mia esperienza.

  1. Lascia solo Silverlight. Microsoft non ha fornito alcuna informazione relativa agli aggiornamenti o una roadmap in oltre un anno. Cinico e critica hanno dichiarato la lingua morta, ma la realtà è che non lo sappiamo. Con la tecnologia Microsoft, don't know == don't use assumendo che tu abbia la possibilità di scegliere. In breve, non userei Silverlight a questo punto perché non sai quanto tempo ci sarà in giro. Ma mi piace lo schema MVVM che fornisce.

  2. Windows XP è previsto per ufficialmente ritirato l'8 aprile 2014. Detto questo, nulla imporrà il vostro attuale datore di lavoro ad aggiornare i propri sistemi a Windows 7 o 8. Tuttavia, è possibile semplificare le modifiche future dell'applicazione evitando tecnologie più strettamente legate al sistema operativo sottostante. Per me, questo significa evitare WPF. Non perché ci sia qualcosa di sbagliato in WPF, ma perché l'ambiente in cui verrà eseguita la tua applicazione sarà presto disponibile nel supporto legacy di fine vita. La peggiore delle ipotesi è che la tua applicazione necessiti di una patch di sicurezza per WPF che non è disponibile su XP.

  3. ASP.NET ha le migliori possibilità di fornire una tecnologia che funzioni nel tuo ambiente e abbia una roadmap attiva di Microsoft.

  4. Molti dei problemi con le applicazioni winForm provengono da codice mal strutturato. Anche se l'utilizzo di MVC4 è controverso, puoi comunque utilizzare i principi e i modelli sottostanti che presenta. Separare la vista dalla logica aziendale (controller) dalla logica di accesso ai dati (modello) è una "cosa buona" e renderà l'applicazione più facile da modificare in futuro. C'è parecchio scritto sul pattern MVC e su molte varianti come MVVM e MVP. Leggi le informazioni e sarai sulla buona strada per incapsulare la responsabilità all'interno dei livelli appropriati della nuova applicazione.

risposta data 24.09.2013 - 21:24
fonte
1

In ogni caso, stai mettendo un altro piolo nella stessa buca; stai solo dicendo che questo piolo è un po 'più rotondo dell'altro, è meglio?

Non c'è motivo per cui un'applicazione ASP.NET MVC non possa funzionare allo stesso modo di un'app ASP.NET WebForms. Ciò richiederà approcci diversi perché i due quadri hanno filosofie radicalmente differenti. Alla fine, WebForms ha gestito più stati per te, ma le funzionalità di stato sono identiche.

Assicurati di chiedere, e considera il motivo per cui è stato scelto ASP.NET MVC prima di presentare una proposta alla gestione che consideri una tecnologia dipendente dal cliente

    
risposta data 25.09.2013 - 01:23
fonte

Leggi altre domande sui tag