Consigli per convertire un sito Web ASP.NET a più progetti su MVC (utilizzando VS2015)

Per un sito così ampio, raccomanderò una transizione graduale.

1. Determina se hai un sito web o un'applicazione web .

   Le applicazioni Web Asp.Net apportano molti vantaggi, ma la più importante è che hanno una "modalità mista" e possono eseguire sia Webforms che MVC dalla stessa applicazione. Se hai un sito, dovrai eseguire la migrazione a un'app. È un processo semplice e relativamente sicuro. Non dovrebbe richiedere più di un giorno o due.

2. Identifica le parti del tuo codice che sono dolorose con cui lavorare o cambiarle spesso.

   Questi sono i tuoi primi obiettivi. Otterrai il più grande successo per te se li affronterai per primi. Non ha senso inserire il codice "fixing" che non cambia mai.

3. Investire in uno strumento di refactoring come ReSharper.

   Non posso seriamente immaginare di intraprendere un progetto del genere senza uno strumento che ti aiuti rapidamente e, soprattutto, in sicurezza a ripulire il tuo codice.

4. Introduci un nuovo progetto di libreria di classi per ospitare l'accesso ai dati e la logica aziendale comune.

   Il progetto sarà in uno stato di flusso per un po 'di tempo ( forse per sempre ). Hai intenzione di voler centralizzare la logica e l'amp; funzionalità comune ai moduli e ai controller.

   A questo punto, è possibile o meno voler introdurre Entity Framework. La cosa più sicura da fare è estrarre l'accesso ai dati in questa libreria, introdurre un'interfaccia e sostituire successivamente i dati ADO.Net con uno nuovo EF più brillante.

5. Avere un piano.

   Un progetto che diventerà rapidamente un pantano se non hai traguardi realistici e ottenibili.

Infine, considera se hai davvero bisogno di passare a MVC per pulire questo, o se sarebbe sufficiente per imparare il modello Model-View-Presenter e refactoring il codice esistente in esso. È un sapore di MVC (il pattern, non il framework) che funziona molto bene con Webforms. Applicato correttamente, ti darà molti dei benefici architettonici che MVC ti darà.

Di solito, la tua unica vera opzione è un aggiornamento graduale alla nuova tecnologia mentre impari nuove storie dal tuo arretrato. In questo modo, continuerai a fornire valore commerciale nel tempo. Una riscrittura è una vendita difficile. Fornisci un piccolo valore commerciale durante questo. E poi alla fine il prodotto fa all'incirca la stessa cosa (valore commerciale quasi zero). E per un po 'di tempo, anche il valore commerciale consegnato viene ridotto perché il nuovo codice necessita di un rafforzamento. (Non solo bug, ma anche casi limite.)

Quindi ha più senso utilizzare l'investimento esistente a meno che le forze del mercato non lo impediscano (ad esempio, il codice VB 5 non verrà eseguito su Windows X). Non solo il lato business, ma molti utenti sono resistenti alla sostituzione di programmi esistenti con quelli nuovi di zecca. È semplicemente troppo cambiamento in una volta (a meno che, di nuovo, non ci sia un motivo valido).

Se stai sviluppando un prodotto con un ciclo di rilascio, potresti avere un'opzione legittima per riscrivere. La portata di quali parti si riscrivono dovrebbe adattarsi bene al programma di rilascio e dovrebbe consentire alcune altre importanti funzionalità. Anche questo è difficile da giustificare senza un avvocato a livello esecutivo e un driver di mercato. (Ad esempio, il debito tecnico sta paralizzando il ritmo di sviluppo, indirizzando .NET 5 nei prodotti futuri, ecc.)

in the full rewrite scenario, is it preferable to combine everything into a single MVC project, keep the existing 60 projects structure or repartition the functionality by an MVC-friendly principle? Currently the project structure matches the URL structure.

La piattaforma particolare che stai utilizzando dovrebbe avere un'importanza organizzativa inferiore rispetto al tuo team e alle tue storie utente. Non penso che l'organizzazione ottimale possa essere risolta senza immergersi in questi ultimi dettagli. Ad esempio, non mi piacciono molto le convenzioni di default del progetto MVC per i singoli team. Ha più senso per più team dove ad es. I controller sono sviluppati da un team di sviluppo e Views sono sviluppati da un team di UX. (Maggiori informazioni sull'organizzazione del progetto qui .)

Hai anche la possibilità di implementare in modo diverso dalla struttura del tuo progetto. Basta documentare il processo di distribuzione se è manuale. (Altrimenti sarà "documentato" nella configurazione / script di implementazione.)

in the gradual converting scenario, what's the most painless process?

Sostituire una pagina principale è probabilmente troppo grande per un primo passo con troppi rischi.

Prenderò prima il frutto basso e appeso, alcune pagine statiche. Ti consentirà di risolvere i problemi di implementazione del nuovo progetto, risolvendo i collegamenti tra i siti e solo quelli generici relativi ai nuovi tipi di progetti.

Vorrei iniziare a guardare le tue storie utente imminenti e identificare quelle in cui le pagine coinvolte potrebbero essere spostate facilmente nella soluzione MVC. Ad esempio, non è un comportamento complesso di postback da tracciare. O dove sono necessarie nuove funzionalità e puoi sviluppare una pagina da zero.

Le pagine WebForm e MVC devono essere in grado di operare insieme, collegarsi tra loro, ecc. I tuoi utenti potrebbero notare visivamente una differenza nelle nuove pagine, ma ovviamente la loro capacità di svolgere le loro attività non dovrebbe essere interrotta. Dal momento che è uno sforzo di basso valore (business-speaking), tutti i principali problemi con il nuovo sforzo possono far cessare e desistere la pressione da altre parti del business.

Nella mia esperienza, a meno che tu non ne abbia fatto un obiettivo primario, il tuo passaggio potrebbe non finire mai del tutto, o potrebbero volerci anni. A un certo punto dovrai creare storie di migrazione specifiche, perché non ci saranno storie di utenti contro il materiale legacy rimanente. Alcune funzioni legacy finiscono per essere troppo di basso valore o ad alto rischio di cambiare come parte di altre storie.

P.S. Dopo aver lavorato per un po 'con il progetto MVC, probabilmente vorrai convertirlo in HTML5 / Angular e Web API. ;) Ti consiglierei di saltare a questo punto, ma è un cambiamento piuttosto scoraggiante nel set di abilità con cui il tuo team può o meno essere a suo agio prima che portino MVC alla cintura.

Bilanciare l'attuale investimento mantenendo la tecnologia rilevante è difficile. Penso che sia uno dei motivi per cui le filosofie "microservice" e "microapp" sono diventate più popolari mentre l'evoluzione tecnologica aumenta in velocità. Poiché i "micro" progetti sono più facili da riscrivere con le nuove tecnologie a patto che tu mantenga le API uguali. Tuttavia, hanno una mancanza di coerenza che li rende difficili da gestire. Dovendo avviare 5 servizi per riprodurre un bug ... dover aggiungere funzionalità di supporto a 3 servizi e 2 app per soddisfare un caso di utilizzo end-to-end. Ecc.