Le migliori pratiche per spostare l'applicazione MS Access di grandi dimensioni verso .Net?

Questo sarà un progetto ampio e molto coinvolto. Sono stato responsabile della migrazione dei database di Access in .NET molte volte, ma mai su questa scala. Sono d'accordo sul fatto che un approccio graduale sarà probabilmente il più realistico. Cercare di affrontare tutto in un colpo è un modo facile per fallire.

Come in altre risposte, il primo e più importante passo sarà spostare tutto in SQL Server. Durante questa operazione, documenta il database se questo non è già stato fatto e identifica le aree per il refactoring, se esistenti. I database di accesso che crescono per soddisfare esigenze in evoluzione spesso hanno modelli di dati che possono essere migliorati quando si guarda al quadro generale.

Successivamente, identifica i moduli dell'applicazione che sono "autonomi". Poiché si tratta di un database do-tutto, probabilmente vi saranno dei moduli completamente disgiunti gli uni dagli altri. Dopo avere questi pezzi disgiunti, identifica uno dei moduli più piccoli che ha più da guadagnare dall'aggiornamento e prendilo per primo.

Durante la migrazione a .NET, non limitarti a fare una semplice copia 1 a 1 dell'applicazione. Raccogli gli input dagli utenti per identificare i punti critici con l'applicazione corrente. Vuoi che la tua prima unità di migrazione sia un enorme successo per ottenere il buy-in completo da tutti gli altri.

Dopo aver completato la prima unità, guarda cosa è successo in termini di sfide, difficoltà, ecc. e usa questo avanzamento.

Una cosa che sconsiglio vivamente sarebbe di implementare moduli parzialmente funzionanti (es: "abbiamo migrato il CRM, ma le caratteristiche X, Y, Z non sono ancora nel nuovo sistema"). Questo farà sì che gli utenti si sentano rapidamente frustrati dall'avere un sistema incompleto quando il vecchio per loro era "perfettamente a posto". Questo tipo di sviluppo può funzionare bene per altri domini, ma non nelle aziende in cui gli utenti vedono "niente di sbagliato" con il vecchio monolito di Access e non capiscono le esigenze di migrazione.

Ecco una sorta di piano per trasformare la tua applicazione MS Access in un'applicazione VB.Net per mutazione.

Questo non è un piano generale, il seguente piano dipende dal progetto che hai descritto.

Passaggio 1: migrazione di tutti i dati in SQL Server

Non utilizzare ODBC per la connessione Accesso a SQL Server, utilizzare invece un progetto di accesso (ADP). Un progetto di accesso è un file di accesso con estensione .adp, ha funzionalità di accesso complete (macro, moduli, report, moduli) ma la connessione è direttamente su un database di SQL Server anziché su un file MDB. I file ADP sono molto compatibili con i file MDB. Sembra che non siano supportati in Access 2010, mentre in realtà la funzione è nascosta ma è supportata molto bene. Come MDE, i file ADP possono essere "compilati" in file ADE.

La migrazione in SQL Server comporta poche modifiche nella struttura e nel codice dei dati, ma è abbastanza facile migrare. Ed è un obiettivo finale, dopotutto.

Dimentica l'attivazione degli eventi del database nel codice VBA o VB.Net. Questo può essere fatto tecnicamente utilizzando le stored procedure estese di SQL Server, ma è un trucco molto brutto. Il tuo progetto ha una vita futura, quindi è meglio imporre la sua struttura dati evitando questo tipo di ponte distruttivo. In generale, giocare con i trigger di database, è intelligente ma abbastanza difficile da mantenere.

Passaggio 2: uniforma l'autenticazione

È una buona cosa che la tua applicazione non si basi sulla sicurezza di accesso (file MDW).

Creare un piano per l'autenticazione di destinazione per l'applicazione VB.Net e quindi definire un modo per migrare l'autenticazione di accesso a questa destinazione in modo da ottenere un'autenticazione uniforme tra le due applicazioni.

Poiché l'autenticazione è trasversale in un'architettura di applicazione, questa sarà più facile da suddividere tra la versione di Access e la versione di VB.Net.

Passaggio 3: preparare una funzione token per creare un ponte tra Access e VB.Net

Hai detto che l'interfaccia utente di accesso dovrà aprire un'interfaccia utente VB.Net con alcuni parametri precisi e anche l'autenticazione. E probabilmente dovrai fare lo stesso nell'altro modo.

Una buona soluzione è creare una piccola funzione token basata su una tabella token: le colonne possono essere un token id (intero), una chiave token (stringa lunga), una data token e un elenco di parametri (stringa lunga o testo ). Ogni volta che Access deve aprire una schermata VB.Net, quindi salvare un token nel database con i parametri, quindi aprire l'applicazione VB.Net con solo l'id token e la chiave token. VB.Net si apre, ricerca l'ID del token nel database, controlla la chiave (questo si applica come autenticazione) e legge i parametri. Quindi si apre alla forma corrispondente e fa ciò che è richiesto. Non dimenticare di dare una durata ai token e di pulire vecchi token.

Se hai bisogno di richiamare da VB.Net ad Access (probabilmente lo farai), allora penso che sia possibile attivare alcuni codici VBA su un file MDB Access aperto, usando OLE.

Passaggio 4: migrazione dell'interfaccia utente e dei moduli schermata per schermata, modulo per modulo

Ora il grosso della preparazione è finito. È possibile iniziare a migrare l'interfaccia utente da Ms Access a VB.Net.

Non ci sono buoni strumenti automatici per farlo. VBA e .Net sono troppo diversi. Devi preparare il tuo lavoro per una tale migrazione. Inizia con una piccola forma, come la casella "Informazioni", e continua da forme semplici a forme complicate. Ovviamente dovrai raggruppare e pianificare alcune migrazioni, ma gradualmente migrerai i tuoi schermi, report e librerie da Ms Access a VB.Net.

Sono stupito che tu abbia fatto tutto ciò con Access. C'è una domanda molto importante che non stai chiedendo .NET Windows Form o .NET WPF. WPF ha una curva di apprendimento più ripida, ma a mio parere è più potente con un'interfaccia utente migliore. Recentemente abbiamo convertito la nostra applicazione commerciale da Forms a WPF e stiamo già ottenendo più vendite. Abbiamo anche aggiunto nuove funzionalità, ma l'interfaccia utente WPF è solo più sexy. Controlla il design del tuo tavolo e puliscilo: ora è il momento. Assicurati di dichiarare tutti i tuoi FK. In Access puoi aggiungere roba al volo piuttosto facilmente alcune volte che roba scivola. Se questa è la tua prima interfaccia utente WPF, crea alcuni prototipi. Potremmo aggiungere di più in WPF che la nuova app abbia più funzioni, meno schermate e meno meno codice. Passerai dall'odiare XAML a quanto lo ami. Considera una struttura come MVVM. Puoi decidere di non utilizzare MVVM (non l'abbiamo fatto) ma di prendere questa decisione.

Dato che hai già una buona conoscenza del modello di oggetti Access, penserei che tu voglia utilizzare Access Interop dalla tua app .NET. Dovrebbe (più o meno) consentire di automatizzare il controllo di un'app Access, senza l'opacità di DDE.

Stai chiedendo una buona pratica su come fare la cosa sbagliata. Non ce n'è uno. Le best practice comprendono come creare efficacemente un sistema manutenibile, in modo che anche se un bus si blocca e una squadra completamente nuova ha bisogno di venire a freddo, lo sviluppo e il supporto possono continuare. Il sistema che descrivi invierà la maggior parte degli sviluppatori in esecuzione per le colline. Hai prodotto costruito con tecnologia obsoleta e vuoi interfacciarti con la tecnologia di oggi. E tu vuoi farlo senza dare una risposta a nessuno degli anti-pattern che hai descritto per il prodotto principale. Quegli sviluppatori che sono disposti ad affrontarlo probabilmente non sono disposti a farlo con le condizioni che proponi.

Tuttavia, il bus non si è arrestato in modo da poter sfruttare il team esistente che comprende il sistema. Il modo migliore per sviluppare gradualmente quello che ho trovato è l'utilizzo della metodologia Agile. Supporta un processo iterativo che affronti i requisiti ad alto rischio nelle prime fasi e risolva bene le esigenze aziendali.

Non conosco una profonda conoscenza del tuo livello di business logic, ma puoi anche accedere ai tuoi database MS Access nella tua applicazione .NET. Se non si tratta semplicemente di recuperare i dati, è possibile implementare una connessione TCP / IP tra i programmi (applicazioni VB6 e VB.NET). Si prega di dare un'occhiata a un articolo su CodeProject .

We decided to gradually move our application towards .Net

Spesso un errore. La migliore pratica è non provare "gradualmente".

even though it is a new language for most of the developers here, we have deep knowledge of VBA and several dozen small projects implemented in VB6.

Non è una buona base per una decisione. Se vuoi imparare una nuova lingua, non imparare VB. Impara C # o qualcosa di ancora meglio come Java.

"un nuovo linguaggio per la maggior parte degli sviluppatori qui, abbiamo una profonda conoscenza di VBA" è una frase in codice comune per "abbiamo un Guru VBA che non vogliamo irritare". È qualcosa che potrebbe anche essere cattivo.

What we are looking for are best practices for gradually moving our extensive GUI

Le migliori pratiche non riguardano "Graduale". Coinvolgono "Scarta interamente".

Le migrazioni graduali che ho visto si sono interrotte perché è così difficile.

Stai meglio facendo questo.

1. Conserva il bene più prezioso . I dati. Spostare tutti i dati su SQL Server. Tutto. Riscrivi tutti gli MS-Access per utilizzare le connessioni ODBC a SQL Server. Proprio adesso.

2. Spara a chiunque crei tabelle o dati temporanei o qualcosa in MS-Access. Tutti i dati devono vivere in un database esterno a MS-Access. I dati in MS-Access sono ciò che sta causando i problemi, quindi fermati subito e assicurati che tutti siano d'accordo. Se non sono d'accordo, trova un nuovo lavoro che non implichi l'hacking in MS-Access mentre stai cercando di sbarazzarti di MS-Access.

3. Trova un framework di reporting che genererà automaticamente report vicino a quello che hai ora. Nessuna programmazione Dagli un tavolo o una vista e batti! è fatto.

4. Enumera tutti i 500 rapporti. Suddividili in report facilmente realizzabili con lo strumento e rapporti più difficili. Dai la priorità a quelli difficili in "Must Have", "Should Have", Could Have "e" Will Do Do Until Later ". Sostituisci i report automatici ei report must-have questo strumento di reporting completamente al di fuori di MS-Access.

   La mia esperienza è che spesso una vista del database viene riutilizzata in circa 20 rapporti. Da quello, immagino che tu abbia 25 viste rilevanti da cui derivano i 500 report. Qualsiasi strumento in grado di automatizzare la produzione di report dovrebbe gestire la maggior parte dei report da una piccola serie di visualizzazioni SQL ben congegnate. Alcuni rapporti saranno troppo complessi o difficili per uno strumento automatico.

5. Trova un framework di sviluppo che costruisca automaticamente le transazioni CRUD.

6. Partizione dei 200 moduli in forme CRUD (che possono essere compilate automaticamente) e forme non CRUD. Tra i non CRUD, la priorità è l'utilizzo delle regole MoSCoW (Must, Should, Could, Will not).

   Spesso, il 60-80% dei moduli di una domanda è costituito da moduli CRUD semplici e automatizzati. Il 20-40% è più complesso e richiede una programmazione più specializzata. Basato su questo, hai forme da 120 a 160 CRUD che non hai bisogno di riscrivere, ma solo di automatizzare. Hai 40-80 transazioni estremamente complesse.

7. Costruisci i form CRUD e i moduli non-CRUD Must-have.

8. Valuta le lacune. Ricalibrare le priorità e iniziare a lavorare sulle parti più importanti dell'elenco "Should-Have".

Probabilmente è più semplice scartare completamente Access. Evita il gradualismo.

Alla fine spenderai tutti i soldi.

Puoi anche preventivarlo e spenderlo ora

Cercare di farlo gradualmente potrebbe essere più costoso a causa della complessità del tentativo di gestire la coesistenza.