¿Mejores prácticas para mover grandes aplicaciones de MS Access hacia .Net?

Tenemos una aplicación de MS Access realmente enorme desarrollada internamente inicialmente para nuestras necesidades personales que luego se convirtió en un software comercial y se vendió con éxito. El software es una especie de "software integral para su negocio" y contiene varios módulos que incluyen el Sistema de Gestión de Documentos, Planificación de Recursos Empresariales, Gestión de Inventario, Gestión de Relaciones con el Cliente, Análisis de Datos, etc. Estamos bastante satisfechos con el actual funcionalidad de la aplicación, pero para satisfacer las solicitudes de nuestros clientes nos damos cuenta de que tenemos que pasar a algo nuevo.

Decidimos mover gradualmente nuestra aplicación hacia .Net porque podemos apegarnos a Visual Basic .Net: aunque es un lenguaje nuevo para la mayoría de los desarrolladores aquí, tenemos un profundo conocimiento de VBA y varias docenas de pequeños proyectos implementados en VB6.

Ya comenzamos a mover la funcionalidad de la capa de datos de nuestra aplicación a MS SQL Server, de modo que cada manipulación y búsqueda de datos se realiza directamente en el servidor.

Lo que estamos buscando son las mejores prácticas para mover gradualmente nuestra amplia GUI (alrededor de 500-600 formas diferentes, incluidos subformularios, alrededor de 200 informes con soporte en varios idiomas, etc.). Siguiendo la reciente solicitud de nuestro cliente potencial para implementar el cifrado de datos asíncrono en documentos en DMS, también nos complacería desacoplar completamente esta parte de MS Access e implementarla en .Net.

La pregunta es cómo integrar sin problemas la aplicación .Net con el sistema MS Access existente, de modo que podamos invocarla con ciertos parámetros (derechos de usuario, etc.) y permitir el intercambio de datos entre esta aplicación y la aplicación MS Access en ejecución.

EDITAR:

Intentamos aplicar algunas prácticas del libro " Patrones de integración empresarial " de Martin Fowler para lograr cierta integración entre la aplicación MS Access y algunas pequeñas utilidades que implementamos en .Net para diversas necesidades. Pero solo logramos usar el patrón de "base de datos compartida" y no estábamos realmente satisfechos con nuestra solución.

Por ejemplo, implementamos una pequeña utilidad que se ejecuta como un servicio de Windows que descarga automáticamente todos los mensajes del servidor de correo utilizando la conexión POP3 y los almacena en una tabla, mientras que todos los archivos adjuntos se almacenan en el sistema de archivos.

Lo que hicimos principalmente fue utilizar ADO.NET para acceder directamente a las bases de datos de MS Access en formato MDB y llenar la tabla con algunos datos procesados ​​(como los datos sobre mensajes de correo del ejemplo anterior: tenemos campos para FROM, TO, CC, BCC, Sujeto y cuerpo).

No hay absolutamente ningún problema para trabajar con el formato de datos MDB de .Net , además, no queremos quedarnos con MDB y actualizar casi todo a MS SQL Server 2008, esto nos da mucha más libertad con respecto a la administración y escalabilidad de los datos.

El principal problema aquí es que no sabemos cómo implementar una especie de "devolución de llamada" en Access para poder activar la ejecución de cierto código VBA en la actualización de datos.

Teníamos grandes esperanzas con MS Access 2010 que admite la activación e inserción de activadores para tablas de datos , pero resultó que solo podemos usar Macros de MS Access para estos activadores y no hay forma de ejecutar ningún código VBA personalizado dentro del activador.

También probamos algunas soluciones con el envío de pulsaciones de teclas directamente a la ventana de MS Access para imitar alguna consulta de datos invocada por el usuario. Esto funciona, pero no creemos que sea una solución real que pueda usarse en la producción.

También investigamos DDE para MS Access, pero no pudimos encontrar una buena solución de muestra que implementara comandos DDE y los utilizara para el intercambio de datos y datos en memoria.

Por lo tanto, el problema principal es que MS Access y la aplicación .Net coexistan e interactúen entre sí.

EDIT2 :

Olvidé mencionar que también implementamos la biblioteca MSMQ en VBA para el paso de mensajes entre .Net y MS Access, el problema fue nuevamente la falta de devolución de llamada aquí: realmente tuvimos que sondear la cola para buscar nuevos mensajes y dado que VBA realmente no es compatible multihilo no era realmente una buena solución.

Este será un proyecto grande y muy complicado. He sido responsable de migrar bases de datos de Access a .NET muchas veces, pero nunca a esta escala. Estoy de acuerdo en que un enfoque gradual probablemente sea el más realista. Intentar asumir todo de una vez es una manera fácil de fallar.

Como en otras respuestas, el primer y más importante paso será mover todo a SQL Server. Mientras hace esto, documente la base de datos si esto aún no se ha hecho e identifique las áreas para refactorizar si existen. Las bases de datos de acceso que crecen para satisfacer las necesidades cambiantes a menudo tienen modelos de datos que se pueden mejorar cuando se observa el panorama general.

A continuación, identifique los módulos de la aplicación que están "autocontenidos". Debido a que esta es una base de datos de hacer todo, probablemente habrá módulos de ella que son casi completamente disjuntos entre sí. Después de tener estas piezas disjuntas, identifique uno de los módulos más pequeños que tenga más que ganar al actualizarse y emprenda primero.

Al migrar a .NET, no solo haga una simple copia 1 a 1 de la aplicación. Recopile información de los usuarios para identificar puntos débiles con la aplicación actual. Desea que su primera unidad de migración sea un gran éxito para obtener la aceptación completa de todos los demás.

Una vez que haya terminado la primera unidad, mire lo que sucedió en términos de desafíos, dificultades, etc., y use esto para avanzar.

Una cosa que desalentaría encarecidamente sería implementar módulos que funcionen parcialmente (por ejemplo, "migramos el CRM, pero las características X, Y, Z aún no están en el nuevo sistema"). Esto hará que los usuarios se sientan frustrados rápidamente por tener un sistema incompleto cuando el anterior para ellos estaba "perfectamente bien". Este tipo de desarrollo puede funcionar bien para otros dominios, pero no en empresas donde los usuarios no ven "nada malo" con el antiguo monolito de Access y no entienden las necesidades de migración.

Aquí hay un tipo de plan para convertir su aplicación MS Access en una aplicación VB.Net por mutación.

Este no es un plan general, el siguiente plan depende del proyecto que haya descrito.

Paso 1: migre todos los datos a SQL Server

No use ODBC para el acceso de conexión a SQL Server, use un proyecto de acceso (ADP) en su lugar. Un proyecto de acceso es un archivo de acceso con una extensión .adp, tiene características de acceso completas (macros, formularios, informes, módulos) pero la conexión está directamente en una base de datos de SQL Server en lugar de un archivo MDB. Los archivos ADP son muy compatibles con los archivos MDB. Parece que no son compatibles con Access 2010, mientras que, de hecho, la función está oculta, pero es muy compatible. Al igual que MDE, los archivos ADP se pueden "compilar" en archivos ADE.

La migración a SQL Server costará pocas modificaciones en la estructura de datos y el código, pero todo es bastante fácil de migrar. Y es un objetivo final después de todo.

Olvídate de desencadenar eventos de base de datos a código VBA o VB.Net. Esto se puede hacer técnicamente usando los procedimientos almacenados extendidos de SQL Server, pero es un truco muy malo. Su proyecto tiene una vida futura, por lo que es mejor hacer cumplir su estructura de datos evitando este tipo de puente de desestructuración. En general, minimice los desencadenantes de la base de datos, es inteligente pero bastante difícil de mantener.

Paso 2: haga que la autenticación sea uniforme

Es bueno que su aplicación no se base en la seguridad de acceso (archivo MDW).

Haga un plan para la autenticación de destino para la aplicación VB.Net, y luego defina una forma de migrar la autenticación de Access a este objetivo para tener una autenticación uniforme entre las dos aplicaciones.

Dado que la autenticación es transversal en una arquitectura de aplicación, será más fácil dividirla entre la versión de Access y la versión de VB.Net.

Paso 3: prepare una característica de token para hacer un puente entre Access y VB.Net

Usted dijo que la interfaz de usuario de Access tendrá que abrir una interfaz de usuario de VB.Net con algunos parámetros precisos y también autenticación. Y probablemente tendrá que hacer lo mismo de la otra manera.

Una buena solución es construir una pequeña característica de token basada en una tabla de token: las columnas pueden ser un identificador de token (entero), una clave de token (cadena larga), una fecha de token y una lista de parámetros (cadena larga o texto). Cada vez que Access necesita abrir una pantalla VB.Net, luego guardar un token en la base de datos con los parámetros, y luego abrir su aplicación VB.Net con solo la identificación del token y la clave del token. Se abre VB.Net, busca la identificación del token en la base de datos, verifica la clave (esto se aplica como una autenticación) y lee los parámetros. Luego se abre en la forma correspondiente y hace lo que se requiere. No olvides dar una duración a las fichas y limpiar las fichas antiguas.

Si necesita volver a llamar desde VB.Net a Access (probablemente lo hará), entonces creo que es posible activar algún código VBA en un archivo de acceso MDB abierto, usando OLE.

Paso 4: migre la IU y los módulos pantalla por pantalla, módulo por módulo

Ahora lo mejor de la preparación está hecho. Puede comenzar a migrar la interfaz de usuario de Ms Access a VB.Net.

No hay buenas herramientas automáticas para hacer esto. VBA y .Net son muy diferentes. Tienes que preparar tu trabajo para tal migración. Comience con un formulario pequeño, como el cuadro "Acerca de", y continúe desde formularios simples hasta formularios complicados. Por supuesto, tendrá que agrupar y programar algunas migraciones, pero gradualmente migrará sus pantallas, informes y bibliotecas de Ms Access a VB.Net.

Me sorprende que hayas hecho todo eso con Access. Hay una pregunta muy importante que no debe hacer .NET Windows Forms o .NET WPF. WPF tiene una curva de aprendizaje más pronunciada, pero en mi opinión es más potente con una mejor interfaz de usuario. Recientemente convertimos nuestra aplicación comercial de Formularios a WPF y ya estamos obteniendo más ventas. También agregamos nuevas funciones, pero la interfaz de usuario de WPF es más sexy. Revise el diseño de su mesa y límpiela: ahora es el momento. Asegúrate de declarar todos tus FK. En Access, puede agregar cosas sobre la marcha bastante fácil algunas veces que las cosas se deslizan. Si esta es tu primera interfaz de usuario WPF, crea algunos prototipos. Podríamos incluir más en WPF que la nueva aplicación tiene más funciones, menos pantallas y menos código. Pasarás de odiar XAML a cómo amarlo. Considere una estructura como MVVM.

Dado que ya conoce bien el modelo de objetos de Access, creo que desea utilizar Access Interop desde su aplicación .NET. Debería (más o menos) permitirle automatizar el control de una aplicación de Access, sin la opacidad de DDE.

No conozco un conocimiento profundo sobre su capa de lógica de negocios, pero también puede acceder a sus bases de datos de MS Access en su aplicación .NET. Si no se trata simplemente de obtener datos, puede implementar una conexión TCP / IP entre sus programas (aplicaciones VB6 y VB.NET). Por favor, eche un vistazo a un artículo sobre CodeProject .

Estás pidiendo una mejor práctica sobre cómo hacer lo incorrecto. No hay uno Las mejores prácticas abarcan cómo crear de manera efectiva un sistema que se pueda mantener, de modo que incluso si un autobús se bloquea y un equipo completamente nuevo necesita quedarse en frío, el desarrollo y el soporte pueden continuar. El sistema que describas enviará a la mayoría de los desarrolladores a correr por las colinas. Tiene un producto construido con tecnología obsoleta y desea interactuar con la tecnología actual. Y desea hacerlo sin abordar ninguno de los patrones anti que ha descrito para el producto principal. Es probable que los desarrolladores que estén dispuestos a abordarlo no estén dispuestos a hacerlo con las condiciones que proponga.

Sin embargo, su autobús no se ha estrellado, por lo que puede aprovechar el equipo existente que comprende el sistema. La mejor manera de desarrollar gradualmente que he encontrado es usar la metodología ágil. Es compatible con un proceso iterativo que aborda los requisitos de alto riesgo desde el principio y aborda bien las necesidades del negocio.

Decidimos mover gradualmente nuestra aplicación hacia .Net

A menudo un error. La mejor práctica es no intentar "gradualmente".

A pesar de que es un lenguaje nuevo para la mayoría de los desarrolladores aquí, tenemos un profundo conocimiento de VBA y varias docenas de pequeños proyectos implementados en VB6.

No es una muy buena base para una decisión. Si desea aprender un nuevo idioma, no aprenda VB. Aprende C # o algo aún mejor como Java.

"un nuevo lenguaje para la mayoría de los desarrolladores aquí, tenemos un profundo conocimiento de VBA" es una frase de código común para "tenemos un VBA Guru a quien no queremos irritar". Eso es algo que posiblemente sea malo, también.

Lo que estamos buscando son las mejores prácticas para mover gradualmente nuestra amplia GUI

Las mejores prácticas no involucran "Gradual". Implican "Descartar completamente".

Las migraciones graduales que he visto se han roto porque es muy difícil.

Es mejor que hagas esto.

1. Preservar el activo más valioso . Los datos. Mueva todos los datos a SQL Server. Todo ello. Reescriba todo el MS-Access para usar conexiones ODBC a SQL Server. Ahora mismo.

2. Despida a cualquiera que cree tablas o datos temporales o cualquier cosa en MS-Access. Todos los datos deben vivir en una base de datos fuera de MS-Access. Los datos en MS-Access son los que causan los problemas, así que deténgase ahora y asegúrese de que todos estén de acuerdo. Si no están de acuerdo, búsqueles un nuevo trabajo que no implique piratear MS-Access mientras intenta deshacerse de MS-Access.

3. Encuentre un marco de informes que generará automáticamente informes cercanos a los que tiene ahora. Sin programación ¡Solo dale una mesa o una vista y golpea! está hecho.

4. Enumere los 500 informes. Partícelos en informes que se crean fácilmente con la herramienta e informes que son más difíciles. Priorice los difíciles en "Debe tener", "Debería haber", Podría haber "y" No lo haré hasta más tarde ". Reemplace los informes automatizados y los informes imprescindibles de esta herramienta de informes completamente fuera de MS-Access.

   Mi experiencia es que una vista de base de datos a menudo se reutiliza en aproximadamente 20 informes. A partir de eso, supongo que tiene 25 vistas relevantes de las cuales se derivan los 500 informes. Cualquier herramienta que pueda automatizar la producción de informes debe manejar la mayoría de sus informes desde un pequeño conjunto de vistas SQL bien diseñadas. Algunos informes serán demasiado complejos o difíciles para una herramienta automatizada.

5. Encuentre un marco de desarrollo que construya transacciones CRUD automáticamente.

6. Particione sus 200 formularios en formularios CRUD (que se pueden construir automáticamente) y en formularios que no sean CRUD. Entre los que no son CRUD, priorice el uso de las reglas MoSCoW (Debe, Debería, Podría, No lo hará).

   A menudo, el 60-80% de los formularios de solicitud son formularios CRUD simples y automatizados. 20-40% son más complejos y requieren una programación más experta. En base a esto, tiene de 120 a 160 formularios CRUD que no necesita reescribir, solo automatizar. Tienes 40-80 transacciones seriamente complejas.

7. Cree los formularios CRUD y los formularios imprescindibles que no sean CRUD.

8. Evaluar las brechas. Vuelva a priorizar y comience a trabajar en las partes más importantes de la lista "Debería haber".

Probablemente sea más fácil descartar Access por completo. Evita el gradualismo.

Vas a gastar todo el dinero eventualmente.

También puede presupuestarlo y gastarlo ahora.

Intentar hacerlo gradualmente puede ser más costoso debido a la complejidad de tratar de gestionar la convivencia.