Remake vecchia applicazione web form in asp.net mvc [duplicato]

Non essere così frettoloso

So che trattare con il codice di altre persone fa davvero schifo, ma devi prendere in considerazione che 1- non conosci la nuova piattaforma MVC e, in fondo alla strada, vorrai rifarlo di nuovo. Considera che ricostruire il progetto richiede anche tempo per poterlo aggiornare.

Nessuna sorpresa

Le persone non gradiscono sorprese nel regno del software. Posso raccontarti un sacco di storie horror di software che sono state rifatte senza che il cliente lo sapesse e sulla sorpresa che rivela, un istantaneo, terribile rifiuto.

La soluzione migliore è parlare con il tuo capo e discutere le opzioni. Potrebbero anche voler integrare più funzionalità o andare in una direzione diversa. Dopotutto, il tuo tempo è il loro denaro.

Un'ultima opzione

Potrebbe essere meglio dedicare più tempo all'apprendimento e ad accumulare lentamente componenti che causano problemi. Sento che stai avendo qualche problema a capire tutte le funzioni del software e andare in un remake con quelle stesse confusioni trascinerà solo quelle incomprensioni nel nuovo progetto.

Domande SO correlate

• Refactor o Rewrite?
• Refactor / riscrivi il codice o continua?

A mio parere, la conversione di un'applicazione che ha richiesto anni per svilupparsi in MVC non è probabilmente realistica. Probabilmente ci vorrà tanto tempo per convertirlo in MVC, perché l'implementazione sarebbe totalmente diversa e dovresti trovare altri modi per implementare le funzionalità esistenti. Dubito che questo cliente che richiede regolarmente miglioramenti sarebbe disposto ad aspettare un paio d'anni mentre stai provando a convertirlo in MVC. Dal punto di vista del business, questo non è solo pratico. Lo cambieresti per te, quindi è più facile per te lavorare con te, il che non è un incentivo aziendale per loro.

Se c'è un aspetto particolare del sistema che ti rende difficile costruire miglioramenti, concentrati sul miglioramento di quell'aspetto del sistema. Rassegnati al fatto che si tratta di un'applicazione di moduli web e trova i modi per renderti più facile lavorare con te. Gli sviluppatori tendono a pensare a ciò che vorrebbero e a come gli piace lavorare, ma devi pensare al cliente e al modo in cui le tue preferenze influenzeranno la loro attività e i loro profitti.

Il mio consiglio è di lavorare all'interno del design attuale per renderne più semplice l'utilizzo con alcune parti.

Sono d'accordo con tutto @ rlb.usa dice . Un altro rischio è che non terminerai mai la migrazione del codice se lo fai un passo alla volta sulla base di richieste di miglioramento / modifica.

Questo potrebbe lasciarti con un mal di testa di manutenzione più grande di quello che hai ora dato che ci sarà ancora meno coerenza nell'architettura. E creerà sicuramente più confusione per il prossimo sviluppatore che arriva.

Se non hai tempo e risorse da dedicare a riscrivere l'applicazione ASP.NET MVC e riscrivendola correttamente, non farlo. Ti troverai in un mondo di dolore. So per esperienza di quanto terribili app WebForms possano essere scritte, ma è uno sforzo enorme per riscriverlo su MVC anche con i vantaggi che avresti ottenuto.

Faresti meglio a fare pesanti refactoring / riscrittura di componenti specifici per renderli più astratti e modulari, e usando MVP o pattern simili per ottenere alcuni dei benefici di MVC senza un trasferimento totale verso quella piattaforma? Potrebbe essere un'opzione migliore. Ovviamente per qualsiasi nuovo sviluppo che deve solo interagire con, non farne parte, l'app legacy dovrebbe essere scritta in MVC, ma pesante refactoring, introduzione di MVP e principi SoC appropriati, e lentamente riscrittura delle parti più disordinate del codice da scrivere correttamente andrà molto più a lungo del semplice demolizione del behemoth di WebForms.

Non c'è quasi nessun punto nella riscrittura da webforms in mvc. Quasi nessun codice sopravviverà alla transizione e, dato che non conosci MVC, il risultato non sarà eccezionale.

The application code is divided into multiple folders representing the different departments and each department has it's own pages for handling general stuff like employee management, reports, budget and also their own information. For example, even though each department uses a different webpage for employee information handling, they want different fields and so it was simpler to create different pages than to use a single page that adapts to each department.

Questa sarà la tua salvezza - ho visto questo tipo di applicazione. Poiché ogni pezzo dell'applicazione è sostanzialmente separato, hai la possibilità di eseguire una migrazione frammentaria a un sistema più sensibile.

Ritaglia una posizione nello spazio URL del server su cui è in esecuzione che puoi inserire un nuovo codice. Riscrivi schermate una alla volta e prova il nuovo codice per assicurarti che funzioni nel modo desiderato. Quindi modificare i collegamenti e i reindirizzamenti nella vecchia applicazione per puntare alle nuove schermate e navigare nelle nuove schermate che rimandano a schermate ancora attive nella vecchia applicazione. Fondamentalmente, avrai due applicazioni che condividono un'interfaccia utente. quindi rimuovi via via la schermata dell'applicazione precedente per schermo e scrivi nuovo codice nella nuova applicazione.

Potrebbe essere necessario trovare un modo per trasferire le informazioni tra le due applicazioni. È possibile impostare la chiave dell'applicazione nel proprio web.config sullo stesso valore per consentire il Single Sign-On tra i due lati. Cerca di evitare di condividere lo stato della sessione, se possibile, (se hai un problema, ti basta.) Elimina vecchi schermi man mano che diventano obsoleti. Se esistono classi sensibili del livello aziendale o classi DAL, estraile in una libreria condivisa; altrimenti, non preoccuparti.

I hanno risposto a una domanda simile (che Non penso sia un duplicato). La mia risposta ha alcuni buoni consigli pratici su come domare un'applicazione WebForms.

Per te, ti consiglio di creare un progetto di prova in Visual Studio. Utilizza SpecFlow e Test UI codificati , Selenium o Watin , quindi prova la schifezza del sito. Una volta che il sito è stato ben coperto con i test, avvia il codice di refactoring, un controllo utente alla volta. Segui le migliori pratiche. Quelle di seguito che ho usato con successo in questa situazione:

• Organizza il tuo codice di accesso al database utilizzando il Pattern del repository
• Non utilizzare DataSet nei controlli utente. Utilizza invece Modelli di dominio .
• Sposta tutta la logica aziendale nei modelli di dominio. Guarda alcuni creazione di modelli di domini malvagi per alcuni buoni consigli.
• Crea classi helper che inizializzano i controlli comuni, come gli elenchi a discesa

Questa è una maratona, non uno sprint.