Ventajas de migrar de la aplicación MS Access a la aplicación .Net

Question

Existe una aplicación existente de tamaño medio desarrollada en MS-Access que actualmente solo utilizan 15 usuarios. Ahora nos encontramos en una situación concreta para eliminar esta aplicación MS-Access existente y desarrollar las mismas funcionalidades en la aplicación .NET (ya sea Windows o Web). Como esta no es una gran aplicación, ¿tenemos algo positivo para mover las funcionalidades a la aplicación .Net? Una comparación entre los dos (.Net Vs MS-Access) - en términos de rendimiento, seguridad, etc., sería apreciada también por las ventajas de desarrollar la aplicación en.Net también me ayudaría.

Answer 1

En mi humilde opinión una comparación general ".NET" vs "MS-Access" no tiene sentido. Puede comparar su aplicación actual con las características/rendimiento/seguridad/etc. esperados de su aplicación migrada, por supuesto, pero uno tiene que saber más sobre los detalles de su aplicación y cómo cree que diseñará su puerto ".NET" .

Cuando usted está buscando razones para justificar los esfuerzos de migración, debe hacerse las siguientes preguntas:

• Hay alguien funciones de la aplicación actual, que no se pueden desarrollar fácilmente utilizando la interfaz de acceso que faltan? Esa sería una buena razón para cambiar a .NET.
• ¿Quién está haciendo el mantenimiento en el futuro? ¿Un programador de C# que solo tiene un poco de experiencia con VBA, o un programador de acceso experimentado con ninguno o solo un poco de conocimiento sobre C#? ¿O eres completamente libre de elegir cualquier tipo de desarrollador de mantenimiento que te guste, así que esto no hace la diferencia?
• ¿Está atascado en una versión específica de MS-Office con su aplicación Access? ¿O se puede migrar fácilmente a una versión más nueva? Desvincularse de una plataforma de Office específica puede ser una buena razón para cambiar la plataforma de desarrollo.
• ¿Qué hay de tu back-end? ¿Está satisfecho con eso (puede mantener el acceso como un backend incluso si su interfaz va a .NET), o necesita una base de datos de cliente-servidor real (en la mayoría de los casos es posible mantener su aplicación de Access como interfaz para ese con mucho menos esfuerzo que una migración .NET completa)? Una base de datos CS como MS-SQL Server le permite a los usuarios más simultáneos y tiene un modelo de seguridad mejorado (por el costo de sobrecarga administrativa, por supuesto), pero de hecho no le da argumentos por los que no puede mantener Access como interfaz.
• Cuántas de las características "RAD" de Access se usan en su aplicación actual (por ejemplo, la posibilidad de que un formulario de acceso cambie automáticamente a un modo de tabla, o las capacidades de creación de informes). Para algunas de estas características no hay una solución preparada en el marco .NET, debe resolverlo de manera diferente o con herramientas de terceros. Eso, por otro lado, sería una buena razón para permanecer en Access.

EDIT: aquí es un artículo de más de 10 años de edad, de Joel Spolsky

http://www.joelonsoftware.com/articles/fog0000000069.html

que parece ser algo relacionado con este tema. Lea lo que piensa sobre tirar una aplicación existente para comenzar de nuevo.

Answer 2

MS Access parece ser una buena combinación cuando su aplicación es principalmente una herramienta para ver y editar registros de datos en una base de datos con formularios simples que están estrechamente relacionados con los diseños de las tablas y necesita poca o ninguna lógica computacional en el proceso completo.

Acabo de volver a implementar una aplicación MS Access con aproximadamente 2000 líneas de código VBA, 10 formularios, 50 tablas y 80 consultas a Java porque contenía muchos cálculos y E/S no relacionadas con bases de datos.La aplicación Java logra el mismo objetivo en aproximadamente 18000 líneas de código. El esfuerzo que se hizo para integrar todas las diferentes bases de datos fue considerable. Esto sería un poco mejor con C# u otra tecnología .NET, pero no significativamente.

Todo depende de para qué está diseñada la aplicación de Access.

Answer 3

En lugar de comparar .net con Access, sospecho que lo que realmente necesita comparar es almacenar datos en Access para almacenar datos en SQL Server.

Recuerde que todas las combinaciones siguientes son válidos:

1. de datos y el usuario en el acceso
2. Los datos almacenados en Access, extremo frontal escrito en .NET
3. Los datos almacenados en SQL Server, delante terminar en el acceso
4. los datos almacenados en SQL Server, el usuario en .NET

en general, si su base de datos y el n Si bien la cantidad de usuarios es cada vez mayor, pero la complejidad de la interfaz no lo es, sugeriría la opción 3. Si los datos y la complejidad aumentan, podría valer la pena y actualizarse a Windows/Web .NET aplicación golpeando SQL Server y haciendo una reescritura completa. Esto requerirá más habilidades especializadas y tiempos de desarrollo potencialmente más largos, pero una flexibilidad infinitamente mayor y más opciones para ajustar el rendimiento.