Best practice per lo spostamento di grandi applicazioni MS Access verso .Net?

Abbiamo un'applicazione MS Access davvero grande sviluppata internamente inizialmente per le nostre esigenze personali, che è stata poi trasformata in un software commerciale e venduta con successo. Il software è una sorta di "software a tutto tondo per la tua azienda" e contiene diversi moduli tra cui il sistema di gestione dei documenti, la pianificazione delle risorse aziendali, la gestione dell'inventario, la gestione delle relazioni con i clienti, l'analisi dei dati ecc. Siamo abbastanza soddisfatti dell'attuale funzionalità dell'applicazione, ma per soddisfare le richieste dei nostri clienti ci rendiamo conto che dobbiamo passare a qualcosa di nuovo.

Abbiamo deciso di spostare gradualmente la nostra applicazione verso .Net perché possiamo attenerci a Visual Basic .Net: anche se qui è un nuovo linguaggio per la maggior parte degli sviluppatori, abbiamo una profonda conoscenza di VBA e diverse decine di piccoli progetti implementati in VB6.

Abbiamo già iniziato a spostare la funzionalità del livello dati della nostra applicazione su MS SQL Server, in modo che ogni manipolazione e ricerca di dati venga eseguita direttamente sul server.

Ciò che stiamo cercando sono le migliori pratiche per spostare gradualmente la nostra ampia GUI (circa 500-600 moduli diversi tra cui sottomaschere, circa 200 report con supporto multilingue, ecc.). A seguito della recente richiesta del nostro potenziale cliente di implementare la crittografia dei dati asincrona sui documenti in DMS, saremo anche felici di separare completamente questa parte da MS Access e implementarla in .Net.

La domanda è come integrare senza problemi l'applicazione .Net con il sistema MS Access esistente, in modo che possiamo invocarla con determinati parametri (diritti utente ecc.) E abilitare lo scambio di dati tra questa applicazione e l'esecuzione dell'applicazione MS Access.

MODIFICARE:

Abbiamo cercato di applicare alcune pratiche del libro " Schemi di integrazione aziendale " di Martin Fowler per ottenere una certa integrazione tra l'applicazione MS Access e alcune piccole utility che abbiamo implementato in .Net per varie esigenze. Ma siamo riusciti a utilizzare solo il modello "database condiviso" e non siamo rimasti molto soddisfatti della nostra soluzione.

Ad esempio, abbiamo implementato una piccola utility in esecuzione come servizio Windows che scarica automaticamente tutti i messaggi dal server di posta utilizzando la connessione POP3 e li memorizza in una tabella, mentre tutti gli allegati sono memorizzati nel file system.

Quello che abbiamo fatto principalmente è stato usare ADO.NET per accedere direttamente ai database MS Access in formato MDB e popolare la tabella con alcuni dati elaborati (come i dati sui messaggi di posta dell'esempio precedente: abbiamo campi per FROM, TO, CC, BCC, Soggetto e corpo).

Non c'è assolutamente alcun problema a lavorare con il formato di dati MDB da .Net , inoltre non vogliamo rimanere con MDB e sovradimensionare quasi tutto a MS SQL Server 2008 - questo ci dà molta più libertà riguardo la gestione e la scalabilità dei dati.

Il problema principale qui è che non sappiamo come implementare una sorta di "callback" in Access in modo da poter attivare l'esecuzione di un determinato codice VBA sull'aggiornamento dei dati.

Avevamo grandi speranze con MS Access 2010 che supporta l' aggiornamento e l'inserimento di trigger per le tabelle di dati , ma si è scoperto che possiamo usare solo macro di MS Access per questi trigger e non è possibile eseguire alcun codice VBA personalizzato all'interno del trigger.

Abbiamo anche provato alcune soluzioni con l' invio di sequenze di tasti direttamente alla finestra di MS Access per imitare alcune richieste di dati invocate dall'utente. Funziona, ma non pensiamo che questa sia una soluzione affidabile che può essere utilizzata in produzione.

Abbiamo anche esaminato DDE per MS Access, ma non siamo riusciti a trovare alcuna buona soluzione di esempio che implementasse i comandi DDE e li usasse per lo scambio di dati e comandi in memoria.

Quindi, il problema principale è far coesistere le applicazioni MS Access e .Net e interagire tra loro.

EDIT2 :

Ho dimenticato di menzionare ciò che abbiamo implementato anche la libreria MSMQ in VBA per il passaggio di messaggi tra .Net e MS Access, il problema era di nuovo la mancanza di richiamata qui: dovevamo davvero sondare la coda per i nuovi messaggi e dato che VBA non supporta davvero il multi-threading non era davvero una bella soluzione.

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

Come in altre risposte, il primo e più importante passo sarà quello di spostare tutto su SQL Server. Nel fare ciò, documentare il database se ciò non è già stato fatto e identificare le aree per il refactoring se esistenti. I database di accesso che crescono per soddisfare le esigenze in evoluzione spesso hanno modelli di dati che possono essere migliorati guardando il quadro generale.

Successivamente, identifica i moduli dell'applicazione che sono "autonomi". Poiché si tratta di un database di tutto, probabilmente ci saranno dei moduli che sono quasi completamente disgiunti l'uno dall'altro. Dopo aver avuto questi pezzi disgiunti, identifica uno dei moduli più piccoli che ha più da guadagnare dall'aggiornamento e affrontalo per primo.

Durante la migrazione a .NET, non limitarti a fare una semplice copia 1 a 1 dell'applicazione. Raccogliere input dagli utenti per identificare i punti deboli con l'applicazione corrente. Volete che la vostra prima unità di migrazione sia un enorme successo per ottenere il completo acquisto da tutti gli altri.

Dopo aver completato la prima unità, guarda cosa è successo in termini di sfide, difficoltà, ecc. E usa questo per andare avanti.

Una cosa che scoraggerei fortemente sarebbe quella di implementare moduli parzialmente funzionanti (es: "abbiamo migrato il CRM, ma le funzionalità X, Y, Z non sono ancora nel nuovo sistema"). Ciò farà sì che gli utenti diventino rapidamente frustrati dall'avere un sistema incompleto quando quello vecchio era "perfettamente perfetto". Questo tipo di sviluppo può funzionare bene per altri domini, ma non nelle aziende in cui gli utenti non vedono "nulla di male" con il vecchio monolito di Access e non comprendono le esigenze di migrazione.

Ecco una specie 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: migrare tutti i dati su 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 Access con estensione .adp, ha funzionalità di accesso complete (macro, moduli, report, moduli) ma la connessione è direttamente su un database SQL Server anziché su un file MDB. I file ADP sono molto compatibili con i file MDB. Sembrano non essere supportati in Access 2010, mentre in realtà la funzionalità è nascosta ma è molto ben supportata. Come MDE, i file ADP possono essere "compilati" in file ADE.

La migrazione a SQL Server costerà poche modifiche nella struttura e nel codice dei dati, ma è abbastanza facile migrare. Ed è dopo tutto un obiettivo finale.

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

Passaggio 2: uniformare l'autenticazione

È positivo che l'applicazione non si basi sulla sicurezza dell'accesso (file MDW).

Preparare un piano per l'autenticazione di destinazione per l'applicazione VB.Net, quindi definire un modo per migrare l'autenticazione di Access su questa destinazione per avere un'autenticazione uniforme tra le due applicazioni.

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

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

Hai detto, l'interfaccia utente di Access 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 è quella di creare una funzionalità token di piccole dimensioni basata su una tabella token: le colonne possono essere un ID token (numero 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, cerca l'ID token nel database, controlla la chiave (vale come autenticazione) e legge i parametri. Quindi si apre al modulo corrispondente e fa ciò che è richiesto. Non dimenticare di dare una durata ai token e di pulire i vecchi token.

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

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

Ora la grande preparazione è fatta. Puoi 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 tale migrazione. Inizia con un piccolo modulo, come la casella "Informazioni", e continua dai moduli semplici a quelli complicati. Ovviamente dovrai raggruppare e programmare alcune migrazioni, ma migrerai gradualmente i tuoi schermi, i tuoi rapporti e le tue librerie da Ms Access a VB.Net.

Sono sorpreso che tu abbia fatto tutto questo con Access. C'è una domanda molto importante che non stai ponendo. NET Windows Forms o .NET WPF. WPF ha una curva di apprendimento più ripida, ma a mio avviso è più potente con un'interfaccia utente migliore. Di recente 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 di WPF è solo più sexy. Rivedi il design del tuo tavolo e puliscilo - ora è il momento. Assicurati di dichiarare tutti i tuoi FK. In Access è possibile aggiungere elementi al volo abbastanza facilmente alcune volte che gli elementi scivolano. Se questa è la tua prima interfaccia utente di WPF, crea alcuni prototipi. Potremmo comprimere di più in WPF che la nuova app ha più funzionalità, meno schermate e meno codice. Passerai dall'odiare XAML a quanto lo ami. Considera una struttura come MVVM.

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

Non conosco una conoscenza approfondita del tuo livello di logica aziendale, ma puoi anche accedere ai tuoi database MS Access nell'applicazione .NET. Se non si tratta semplicemente di recuperare dati, è possibile implementare una connessione TCP / IP tra i programmi (applicazioni VB6 e VB.NET). Dai un'occhiata a un articolo su CodeProject .

Stai chiedendo le migliori pratiche su come fare la cosa sbagliata. Non ce n'è uno. Le migliori pratiche comprendono come creare in modo efficace un sistema gestibile, in modo che anche se un autobus si arresta in modo anomalo e un team completamente nuovo deve subire un rallentamento, lo sviluppo e il supporto possono continuare. Il sistema che descrivi invierà la maggior parte degli sviluppatori in esecuzione per le colline. Hai un prodotto costruito con tecnologia obsoleta e vuoi interfacciarti con la tecnologia di oggi. E vuoi farlo senza affrontare nessuno degli schemi anti che hai descritto per il prodotto principale. Quegli sviluppatori che sono disposti ad affrontarlo non sarebbero probabilmente disposti a farlo con le condizioni che proponi.

Tuttavia, il tuo autobus non si è schiantato in modo da poter sfruttare il team esistente che comprende il sistema. Il modo migliore per sviluppare gradualmente che ho trovato è usare la metodologia agile. Supporta un processo iterativo che affronta tempestivamente i requisiti di rischio elevato e risponde bene alle esigenze aziendali.

Abbiamo deciso di spostare gradualmente la nostra applicazione verso .Net

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

anche se è un nuovo linguaggio per la maggior parte degli sviluppatori qui, abbiamo una profonda conoscenza di VBA e diverse decine di piccoli progetti implementati in VB6.

Non è un'ottima 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 forse è anche brutto.

Ciò che stiamo cercando sono le migliori pratiche per spostare gradualmente la nostra ampia GUI

Le migliori pratiche non prevedono "Graduale". Coinvolgono "Elimina interamente".

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

Farai meglio a farlo.

1. Preserva la risorsa più preziosa . I dati. Sposta tutti i dati su SQL Server. Tutto. Riscrivi tutti gli accessi MS per utilizzare le connessioni ODBC a SQL Server. Proprio adesso.

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

3. Trova un framework di report che genererà automaticamente report vicini a quello che hai adesso. Nessuna programmazione. Basta dare un tavolo o una vista e bang! E 'fatto.

4. Enumera tutti i 500 rapporti. Partizionarli in report facilmente compilabili con lo strumento e report più difficili. Dai la priorità a quelli difficili in "Devi avere", "Dovrebbe avere", Potresti "e" Non lo faremo più tardi ". Sostituisci i report automatici e i report indispensabili questo strumento di reporting completamente al di fuori di MS-Access.

   La mia esperienza è che una vista del database viene spesso riutilizzata in circa 20 report. Da ciò, immagino che tu abbia 25 punti di vista pertinenti da cui derivano i 500 rapporti. Qualsiasi strumento in grado di automatizzare la produzione di report dovrebbe gestire la maggior parte dei report da un piccolo set di visualizzazioni SQL ben predisposte. Alcuni report saranno troppo complessi o difficili per uno strumento automatizzato.

5. Trova un framework di sviluppo che crea automaticamente transazioni CRUD.

6. Partiziona i tuoi 200 moduli in moduli CRUD (che possono essere creati automaticamente) e moduli non CRUD. Tra i non-CRUD, dai la priorità usando le regole MoSCoW (Must, Should, Could, Won't).

   Spesso, il 60-80% dei moduli di domanda è costituito da moduli CRUD semplici e automatizzati. Il 20-40% è più complesso e richiede una programmazione più qualificata. Sulla base di questo, hai 120-160 moduli CRUD che non hai bisogno di riscrivere, basta automatizzare. Hai 40-80 transazioni seriamente complesse.

7. Crea i moduli CRUD e i moduli non CRUD indispensabili.

8. Valuta le lacune. Riordina le priorità e inizia a lavorare sulle parti più importanti dell'elenco "Dovresti avere".

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

Alla fine spenderai tutti i soldi.

Puoi anche stanziarlo e spenderlo ora.

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