ASP classico in ASP.net o ASP.net MVC

Abbiamo un'applicazione web che si sviluppa in ASP classico e si è evoluta in 5 anni nella sua forma attuale che ha centinaia di pagine, un enorme database e oltre 10000 utenti attivi che attraversano almeno più di 10 pagine al giorno.

Ora, volevamo aggiornarlo all'ultima versione di .net. Inizialmente abbiamo pensato di riscrivere l'intera app, ma dopo aver analizzato lo scenario abbiamo scoperto che non è un'opzione praticabile e non è stata suggerita da molti esperti. Non abbiamo ancora deciso come farlo in altri modi, ma abbiamo avuto qualche idea su come ottenere la riscrittura in faccia.

Opzione 1: abbiamo pensato di identificare i moduli principali in questa applicazione e riscriverli uno per uno separando l'applicazione in diversi livelli come database (esistente), quindi logica aziendale e vista. In questo modo i moduli di nuova concezione verranno aggiunti al sistema esistente e le nuove pagine sostituiranno quelle vecchie in quel particolare modulo. Allo stesso tempo, possiamo testare i nuovi livelli insieme al vecchio sistema e rilasciarli quando ci sentiamo sicuri. Abbiamo anche pensato di sviluppare un tipo di struttura API per la logica aziendale e alla quale si accederà dalla vista come applicazione esterna.

Opzione 2: Al momento abbiamo creato un modulo semplice e l'abbiamo usato nella classica pagina ASP attraverso un IFrame, anche se è stato abbastanza problematico inviare dati tra ASP classico e nuova pagina nell'IFrame.

Questo è solo in fase di pianificazione su come dovremmo ottenere la riscrittura dell'intera applicazione senza disturbare la base di utenti.

Voglio ottenere opinioni, opinioni e suggerimenti su altri programmatori su cui dovremmo avvicinarci in tale scenario? se qualcuno ha affrontato questo tipo di scenario, si prega di condividere anche la tua opinione.

Inoltre vorrei sapere che usando ASP.net MVC mi aiuterà in questo?

AGGIORNAMENTO : Grazie per entrambe le risposte per aver pubblicato le tue opinioni. Vorrei ottenere più input su entrambe le opzioni che ho specificato sopra durante la migrazione dell'applicazione da asp classico a asp.net o asp.net mvc. Sarebbe di grande aiuto per me, se tutti voi potete attraverso le vostre opinioni, punti e pensieri sulla parte della migrazione piuttosto che il punto di scegliere asp.net o asp.net mvc.

Vorrei iniziare dicendo "Sento il tuo dolore, brutha". Ci sono passato 3 anni fa e vorrei che MVC fosse maturato a quel punto perché la soluzione WebForms che ho progettato assomiglia abbastanza bene al modello MVC senza avere effettivamente le librerie Microsoft costruite per me (ovviamente, ci sono stati diversi abbaglianti "Why hell hell ho fatto quello "differenze).

Ho anche finito per usare iFrames per gestire le differenze di contenuto usando .Net come applicazione principale e asp classico come schiavo. Ho sviluppato l'architettura del framework in .Net e l'ho implementata. Le classiche pagine ASP sono state poi "abbattute" da pezzi di presentazione non necessari (include e quant'altro) e caricate in iFrames. I dati sono stati quindi passati attraverso l'URL utilizzando una crittografia personalizzata. Per essere sicuri che l'autenticazione non potesse essere falsificata facilmente e che alla pagina si accedesse rompendo la stringa di query, abbiamo anche utilizzato i gestori Wildcard in IIS che hanno costretto .Net ad autenticarsi prima di analizzare le pagine ASP classiche.

Detto questo, la mia raccomandazione sarebbe di andare subito a MVC.

1. MVC ti darà accesso al routing a livello global.asax. Con una manipolazione intelligente di un controller, è possibile sviluppare i propri modelli in modo adeguato e disporre di un controller comune che gestisca tutte le classiche richieste ASP, se necessario.
2. MVC renderà molto semplice l'aggiunta di un progetto di test e consentirà di riformattare i singoli pezzi dell'applicazione in base alla nuova struttura del modello, fornendo al contempo un'adeguata copertura del test per assicurarsi che tutto vada bene. Il valore di questo è assolutamente incalcolabile perché in ogni codice refactor la copertura è una grande preoccupazione.
3. MVC segue un approccio alla presentazione più scriptato rispetto a WebForms. WebForms cerca di mescolare tutto come se fosse una sorta di applicazione stateful (che non lo è), e questo può essere un vero shock culturale per le persone abituate alla classica asp. Non fraintendetemi, i vostri sviluppatori subiranno uno shock culturale a prescindere da dove vieni, ma se riesci a eliminare un po 'di quello shock dal livello di presentazione potresti trovare un successo maggiore.

Mi piacciono sia WebForms che MVC (anche se lo ammetto con l'introduzione di Razor, sto diventando un po 'distorto verso MVC). Entrambi hanno il loro posto, e penso che un'applicazione come quella che descrivi possa essere ideale per un'implementazione MVC, in particolare data la natura "sfalsata" che dovrai adottare per distribuire i pezzi di applicazione refactored.

In ogni caso, penso che devi assicurarti che l'applicazione .Net sia sempre l'applicazione principale quando si tratta di autenticazione / autorizzazione / routing / ecc. Un mio collega ha implementato la sua migrazione su un'applicazione simile con ASP classico come genitore, e ha avuto un gran numero di problemi quando si è finalmente arrivati ​​a integrare tutto di nuovo insieme.

Scegliere ASP.NET MVC non renderà necessariamente più semplice la transizione e potrebbe in effetti renderla più difficile. Tuttavia, quando hai già scelto di affrontare questa grande impresa, perché non impiegare il tempo per andare avanti e passare alla piattaforma più adatta ai tuoi piani?

La migrazione ad ASP.NET (sans MVC) sarà "più semplice", nel senso che puoi generalmente eseguire porte diritte della tua logica esistente senza dover fare molti refactoring, a condizione che non stai facendo molte cose esotiche con ASP classico. I risultati saranno soddisfacenti e relativamente familiari alle persone che hanno già familiarità con l'applicazione. Otterrai vantaggi nel senso che ogni applicazione trasferita dal classico ASP ad ASP.NET ne beneficia .

La migrazione ad ASP.NET MVC richiederà più lavoro. Probabilmente richiederà una nuova ricerca del modello dell'applicazione per adattarlo al modello MVC . Questa è generalmente una buona cosa (tm) perché incoraggia comportamenti positivi come la separazione delle preoccupazioni. Probabilmente l'applicazione risultante non assomiglierà molto a tutto ciò che esiste, ad eccezione dei pezzi logici di base. Otterrai anche altri vantaggi . Sarà un grande cambiamento culturale e ci vorrà un po '(ri) educazione del team di sviluppo per capire "come scrivere MVC" correttamente.

Da notare che Microsoft non sta abbandonando WebForms secondo ScottGu (già un anno fa), ma non credo sia difficile fare appello al fatto che se / quando decidono di eliminare gradualmente una di queste due tecnologie, sarà WebForms.

Concordo pienamente sul fatto che ASP.NET MVC sia la strada da percorrere. Non sarà facile, non sarà più facile, ma è sicuramente molto più a prova di futuro rispetto a WebForms. Sebbene WebForms non sia stato certamente abbandonato, le applicazioni che li utilizzano diventano sempre più ingombranti da gestire man mano che le applicazioni diventano sempre più grandi.

Scoraggio vivamente l'uso di WebForms su "grandi" applicazioni.

Mi piace l'opzione 1) (con MVC) molto meglio dell'opzione 2) in quanto ti consente di evolvere l'applicazione in modo incrementale, senza dover accoppiare le due app troppo come faresti con l'approccio iFrames.

Ho avuto qualche esperienza con la migrazione di una vecchia app su ASP.Net e una delle sfide era la condivisione di alcune risorse come lo stato della sessione tra le due app. Ciò può essere risolto facendo in modo che un'app chiami l'altra sul lato server tramite le informazioni sui cookie dal browser dell'utente. Naturalmente, è possibile eseguire anche altre condivisioni di informazioni tra app tramite routing URL e stringhe di query, un approccio naturale con MVC.

Inoltre, identificare i moduli appropriati da migrare per primi può essere una sfida, ma potresti iniziare con tutte le nuove funzionalità in fase di sviluppo su MVC per impedire la migrazione di più elementi che finiscono nel garage. Quindi forse scegli sezioni che hanno un arretrato significativo di rilavorazioni o correzioni di bug da eseguire in seguito poiché l'app MVC diventerebbe quindi una forma di refactoring, usando il tuo vecchio sistema per stabilire i risultati previsti come suggerisci. Non dimenticare di sfruttare anche la testabilità di MVC aggiungendo test unitari e test di collaudo automatici (ad es. SpecFlow / Watin) durante questo refactoring. Un vantaggio di quest'ultimo tipo di test è che potresti verificare che passino sul vecchio sistema e quindi applicare gli stessi test al tuo nuovo codice per questo e futuri refactoring.