ASP classico a ASP.net o ASP.net MVC

Vorrei iniziare dicendo: "Sento il tuo dolore, brutha". L'ho passato 3 anni fa e mi auguro che MVC sia maturata a quel punto perché la soluzione WebForms che ho progettato è abbastanza simile al modello MVC senza che le librerie Microsoft abbiano effettivamente costruito per me (ovviamente, ci sono stati molti abbaglianti "Perché diavolo ho fatto "differenze".

Ho anche finito con l'utilizzo di iFrame per gestire le differenze di contenuto utilizzando .Net come applicazione principale e asp classico come slave. Ho sviluppato l'architettura del framework in .Net e l'ho implementata. Le classiche pagine asp venivano quindi "selezionate" di parti di presentazione non necessarie (include e whatnot) e caricate in iFrame. I dati sono stati quindi passati attraverso l'url utilizzando una crittografia personalizzata. Per assicurarsi che l'autenticazione non possa essere falsificata facilmente e la pagina a cui si accede rompendo la stringa di query abbiamo anche utilizzato gestori di caratteri jolly in IIS che hanno forzato .Net all'autenticazione prima di analizzare le pagine asp classiche.

Dato questo, la mia raccomandazione sarebbe quella di andare direttamente su MVC.

1. MVC ti darà accesso al routing a livello globale.asax. Con una manipolazione intelligente di un controller, è possibile sviluppare i modelli in modo corretto e disporre di un controller comune che gestisca tutte le richieste ASP classiche necessarie.
2. MVC renderà molto semplice l'aggiunta di un progetto di test e ti consentirà di ridefinire le singole parti dell'applicazione sulla base della nuova struttura del modello fornendo al tempo stesso una copertura di prova adeguata per assicurarti che tutto vada bene. Il valore di questo è assolutamente incalcolabile perché in ogni codice di refactoring la copertura è un problema enorme.
3. MVC segue un approccio alla presentazione più programmato rispetto a WebForms. WebForms cerca di mescolare tutto come se fosse una sorta di applicazione stateful (che non è), e questo può essere piuttosto uno shock culturale per le persone abituate al classico asp. Non fraintendetemi, i vostri sviluppatori subiranno uno shock culturale indipendentemente da dove andate, ma se riuscite a eliminare un po 'di quello shock dal livello di presentazione, potreste trovare un maggiore successo.

Mi piacciono sia WebForms che MVC (anche se ammetto che con l'introduzione di Razor sto diventando un po 'prevenuto nei confronti di MVC). Entrambi hanno i loro posti, e penso che un'applicazione come quella che descrivi possa essere idealmente adatta per un'implementazione di MVC, in particolare data la natura "scaglionata" che dovrai adottare nella distribuzione di pezzi di applicazione refactored.

In qualunque modo tu vada, penso che devi assicurarti che l'applicazione .Net sia sempre l'applicazione madre quando si tratta di autenticazione / autorizzazione / routing / ecc. Un mio collega ha implementato la sua migrazione su un'applicazione simile con il classico asp come genitore, e ha avuto un gran numero di problemi quando è arrivato finalmente a integrare tutto insieme.

Il passaggio a ASP.NET MVC non renderà la transizione necessariamente più semplice e potrebbe infatti renderla più difficile. Tuttavia, quando hai già scelto di passare attraverso questa grande impresa, perché non prendere il tempo per andare avanti e passare alla piattaforma che si adatta meglio ai tuoi piani?

La migrazione ad ASP.NET (sans MVC) sarà "più facile" nel senso che in genere è possibile eseguire porte diritte della logica esistente senza dover eseguire un gran numero di refactoring, a condizione che non si stia facendo molto 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 a ASP.NET riceve vantaggi .

Migrare ad ASP.NET MVC sarà più lavoro. Sarà probabilmente necessario rearchitecting il tuo modello di applicazione per adattarsi all'interno del modello MVC . Questa è generalmente una buona cosa (tm) perché incoraggia comportamenti buoni come la separazione delle preoccupazioni. L'applicazione risultante probabilmente non assomiglierà a nulla di ciò che hai esistente, ad eccezione dei pezzi della logica di base. Otterrai 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, Microsoft non sta abbandonando WebForms secondo ScottGu (a partire da un anno fa), ma non penso sia difficile da fare la chiamata che se / quando decidono di eliminare una di queste due tecnologie, sarà WebForms.

Sono assolutamente d'accordo che ASP.NET MVC è la strada da percorrere. Non sarà facile, non sarà più facile, ma è sicuramente una prova molto più futura di WebForms. Sebbene WebForms non sia stato abbandonato, le applicazioni che li utilizzano diventano sempre più ingombranti da mantenere man mano che le applicazioni diventano sempre più grandi.

Sconsiglio vivamente l'uso di WebForms in "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 iFrame.

Ho avuto qualche esperienza con la migrazione di una vecchia app in 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'altro sul lato server tramite le informazioni sui cookie dal browser dell'utente. L'altra condivisione di informazioni tra le app può anche essere fatta tramite l'URL routing e le stringhe di query, che è 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à sviluppate su MVC per impedire la migrazione di altre cose che finiscono nel garage. Quindi, se necessario, seleziona le sezioni che presentano un significativo arretrato di rielaborazioni o correzioni di bug, in quanto l'app MVC diventerà quindi una forma di refactoring, utilizzando il tuo vecchio sistema per stabilire i risultati attesi come suggerisci. Non dimenticare di sfruttare anche la testabilità di MVC aggiungendo test unitari e test di accettazione automatici (ad esempio SpecFlow / Watin) durante questo refactoring. Un vantaggio di quest'ultimo tipo di test è che è possibile verificare che trasmettano il vecchio sistema e quindi applicare gli stessi test al nuovo codice per questo e futuri refactoring.