Quali sono alcune buone tecniche per convertire un'applicazione Ms Access in un'applicazione .Net?

Question

Abbiamo un'app Ms Access di 12 anni che usiamo per il nostro sistema di magazzino e fatturazione dell'inventario principale. È già in esecuzione su un back-end di SQL Server, ma tutti i moduli e i report "logici" sono in Access. Dopo aver sperimentato le enormi quantità di fanghi di manutenzione necessari per trasformare le transazioni di inventario da non temporali a temporali, mi sono reso conto che un giorno avrei dovuto convertire questa cosa in codice in modo da poter gestire meglio la logica in un ambiente molto più gestibile e testabile.

Quali sono alcune tecniche che mi permetterebbero di convertirlo in un'applicazione .Net in modo gestibile ed efficiente?

Un'idea era convertire le query in stored procedure, quindi convertire l'app in un progetto Adp, ma non ho ancora idea di come gestire i moduli e i rapporti.

Inoltre, sono l'unico sviluppatore della mia azienda, se questo è importante.

Answer 1

Dato che hai già asp.net con qualche logica aziendale, potresti aprirlo per accedere come servizio web (file asmx). Google per Microsoft Office Web Services Toolkit per la tua versione di accesso (xp / 2003 ecc.) E questo scriverà classi proxy vba per farti chiamare il servizio web. È possibile associare i dati del servizio Web ai moduli tramite il codice (vba per leggere e scrivere sui controlli) o creare tabelle temporanee locali con i dati del servizio Web e utilizzare l'associazione di accesso regolare.

A seconda di ciò che si è più a proprio agio con (code / tsql) è possibile inserire la logica nelle procedure memorizzate o in un livello di logica aziendale o ibrido (entrambi). Trovo più semplice testare il codice rispetto alle procedure memorizzate e mi piace non essere legato al server sql per la logica aziendale, ad esempio se si desidera modificare il database o si desidera sviluppare / testare componenti offline senza un database. Le nuove funzionalità .net come LINQ hanno prestazioni piuttosto buone, quindi non è necessario fare affidamento su procedure memorizzate per le attività del database.

Mantieni l'interfaccia utente front-end di accesso fino a quando non hai effettuato il refactoring dell'accesso ai dati web / della tua logica aziendale. È quindi possibile creare un'app asp.net che utilizza i servizi Web o un'app winform, se lo si desidera. (Stai lontano da wpf, come interfaccia utente, per il momento in quanto è una curva di apprendimento ripida e non ha ancora un datagrid che può essere paragonato alla vista del foglio dati di accesso.)

Rapporti

I rapporti di accesso possono essere convertiti in servizi di segnalazione SQL Server (vba nei rapporti non è ingrandito ed è meglio scrivere alcuni tsql nelle procedure memorizzate). Se non si dispone del prodotto server sql completo, è comunque possibile utilizzare il controllo reportviewer per scrivere report (consultare http: // www.gotreportviewer.com/ ) in asp.net (o winform con la versione standard o fino a Visual Studio) vincolante per i set di dati ado.net.

Altre opzioni: Puoi scrivere dll .net e usare l'interoperabilità com. Questo approccio consente di iniziare a scrivere funzionalità gradualmente. Non utilizzare l'interfaccia utente .net ad es. una forma di win in quanto non giocherà bene con l'accesso all'interfaccia utente. È possibile scrivere la logica di business o la logica di accesso ai dati e quindi chiamare queste classi da vba. È quindi possibile spostare questo codice su asp.net o servizi Web, se necessario.

Cose da escludere:

Non mi piace l'approccio di scrivere una nuova app con versioni affiancate. Come singolo sviluppatore hai abbastanza di cui preoccuparti. Probabilmente finirai per aggiungere funzionalità in entrambe le versioni e eseguire il debug di due versioni anziché di una.

L'interoperabilità dei moduli vb6 non funziona per l'accesso.

ADP come dichiarato è piuttosto morto. (Non mi sono mai piaciuti perché uso spesso tabelle locali per ottimizzare le prestazioni e possono essere chiamate solo tramite codice e non collegate)

Potresti essere in grado di convertire i tuoi moduli vba e moduli di classe in vb.net usando la procedura guidata di aggiornamento di Visual Basic (in Visual Studio) ma non ingrandisce tutto (ad es. codice dao / ado in codice ado.net) e non crea codice ottimizzato per .net e potrebbe non essere facile scrivere test unitari a seconda del design del codice vba. Ti consiglio di riscrivere il codice (prova Test Driven Development se sei seriamente interessato ai test per vedere se ti piace).

Answer 2

Risposta breve: la migrazione non sembra qualcosa di facilmente automatizzabile.

La mia ipotesi è che la soluzione migliore sia quella di riscrivere (e installare) il sistema un pezzo alla volta, anche se (forse) costringe i tuoi utenti a eseguire le vecchie e le nuove versioni fianco a fianco per un po 'per usa diversi bit di funzionalità. Puoi ridurre al minimo questa seccatura considerando attentamente quali funzioni migrare e in quale ordine.

Ad esempio, potresti avere un utente il cui ruolo lavorativo richiede che lui o lei utilizzi solo una schermata tutto il giorno. Se migra prima quella schermata con le funzionalità di accompagnamento, quell'utente può essere immediatamente sul nuovo sistema e lasciare indietro quello vecchio, riducendo il carico di manutenzione.

Quindi queste sono solo alcune idee basate su non troppe informazioni. Spero che questo aiuti comunque.

Answer 3

Vorrei considerare il Interop Forms Toolkit . A quanto ho capito, questo strumento semplifica l'utilizzo dei moduli .NET da VB6, quindi forse può essere utilizzato anche da Microsoft Access? In tal caso, potrebbe essere utile migrare l'applicazione in .NET in modo incrementale. Facendo una ricerca veloce, non sono stato in grado di trovare alcuna guida su come usarlo con Microsoft Access, quindi mi scuso se questo si rivela essere un vicolo cieco.

Answer 4

La conversione in adp non sarà una buona soluzione a lungo termine: questa tecnologia è abbandonata da Microsoft.

Se vuoi passare a .net (perché? hai un motivo per favorire .net?) ti suggerisco di iniziare a leggere, provare a creare alcune semplici app e quindi iniziare l'attività di conversione di questo database in un'applicazione .

Ma ...

Penso che tu e la compagnia dovete pensare ai rischi connessi a questo progetto. Cosa succederà se ti ammali, proprio nella settimana in cui la direzione ha bisogno di alcuni rapporti che non esistono già? Ti suggerirei di cercare una piccola società di sviluppo software locale, che saranno lieti di aiutarti. Forse puoi organizzare di continuare a essere lo "sviluppatore principale" e utilizzarli solo per il backup.

Answer 5

Ho un problema simile e l'ho risolto creando un sistema di distribuzione con versione nel front-end di Access (afferrare ed estrarre un file CAB), capire la manipolazione di AppDomain necessaria per poter caricare la versione corretta di CLR in Access elaborare, caricare un file .config e pubblicare i dati in entrambi i modi .

Utilizza chiamate DLL C standard, quindi non è richiesta la registrazione COM, ma purtroppo non è supportato Unicode.

Invia comando - Generico, avrei potuto fare tutto con questo. Modulo aperto: destinato a essere un "drop in" sostituzione per DoCmd.OpenForm Apri rapporto: destinato a essere un "drop in" sostituzione per DoCmd.OpenReport

Quindi crea un nuovo report o migra uno esistente su SSRS, rendi il formato standard, quindi modifica DoCmd.OpenReport in netDoCmd.OpenReport in Access.

Segui una convenzione di denominazione per sapere da dove caricare i rapporti e un metodo standard per estrarre i dati necessari per il rapporto.

Ora sto migrando un modulo o un report come permesso di capacità, o quando viene richiesto un cambiamento.

Perché chi può interrompere lo sviluppo delle funzionalità per un anno per fare tutto in un colpo solo?

Tuttavia, MDI non funziona correttamente. Penso che ci sia ancora del lavoro da fare su SetParent e UPDATE_UISTYLE

Tutto ciò rende l'interfaccia utente in corso e nella finestra con Access. Costruisco tutto nelle DLL e il passaggio finale sarà la creazione di un EXE che carica il "primo modulo" e utilizzalo per sostituire il front-end di Access.