Estrategias para el reemplazo de objetos sistémicos

Question

Actualmente nos estamos embarcando en la sustitución de la pila ADO.NET en nuestra aplicación C# con Linq.

Debido a que la aplicación no se diseñó con una capa de abstracción de datos, hay llamadas ADO en casi cada capa de la aplicación a tal grado que compartimentar cualquier objeto e intentar convertirlo a Linq significa que se ejecuta un laberinto de agujeros de conejo.

Lo que estoy preguntando son estrategias o enfoques para abordar tales cambios sistémicos al por mayor mientras se aseguran las pruebas adecuadas y un período mínimo de desactivación de las herramientas de caída (cambios en la plataforma en cualquier momento y vuelvo a ella más adelante fecha).

Hemos jugado con la siguiente:

• crear un objeto de espejo de cada objeto con el nuevo código = tienen que mantener 2 bases de código hasta la conversión completa
• delante de todos los nombres de las funciones de las funciones de ADO con ADO_ y crear versiones de Linq con el nombre original
• Tener un FLAG de todo el sistema para indicar si se debe usar ADO o Linq y ajustar cada llamada ADO con if (FLAG) {ADO} else {Linq} = tener que volver después de la conversión y eliminar todo ADO refs

Cada sugerencia hasta el momento es vergonzosa.

¿Qué chicos/chicas sugieren?

NOTA: Eliminé '(ADO a enlace)' del título porque estoy buscando respuestas y prácticas más genéricas y no solo limitado a la conversión de ADO a Linq utilizada como ejemplo aquí.

Answer 1

Realmente debe tener pruebas unitarias automatizadas antes de realizar cambios. De hecho, no debe hacer cambios para el código que no está cubierto por pruebas unitarias al menos 80%.

En el mundo real, las pruebas unitarias a menudo no existen. Por otro lado, hacer cualquier refactorización sin pruebas unitarias puede arruinar totalmente su código, haciendo que la Administración sea aún menos probable que le permita hacer cambios en el futuro. ¿Qué hacer?

Usando una herramienta como ReSharper, puede comenzar aplicando algunas de las refactorizaciones "más seguras". Con cuidado, no hay ninguna razón por la cual no pueda tener éxito en el uso repetido de "Método de extracto" para mover su ADO.Código NET en métodos separados, "Hacer método estático" si no era estático, luego "Mover método" o "Hacer método no estático" para mover el método a una clase separada.

Una vez que haya sacado el código, puede comenzar a escribir algunas pruebas automatizadas. En esta etapa, no es necesario que sean "pruebas unitarias" en el sentido estricto de la palabra. En particular, se debe permitir que estas pruebas funcionen con la base de datos.

Cuando solo le quedan códigos que no pueden probarse fácilmente en una unidad, puede entonces, cuidadosamente comenzar a hacer que ese código sea más comprobable. Puede hacer cosas como convertir conjuntos de métodos estáticos en métodos de instancia de nuevas clases. También puede comenzar a introducir la inyección de dependencia, para que sea más fácil probar usando objetos simulados. Pero sé muy cuidado aquí - estás modificando el código que no tiene pruebas automatizadas, y estarás utilizando refactorizaciones que realmente pueden romper cosas.

Una vez que haya obtenido el código adecuadamente probado, luego puede reorganizar el código para que tenga más sentido, y luego modificarlo para hacer que use LINQ si lo desea.

Answer 2

Aún puede aprovechar todos sus procedimientos/funciones almacenados originalmente creados para su solución con Linq2SQL. Usando algo como las estrategias expresadas en Working with Legacy Code de Micheal Feather, podría crear límites alrededor de las regiones de la aplicación y actualizarse dentro de esos límites.

La estrategia que he utilizado en el pasado es mantener/ignorar la base de datos y sus objetos. Luego, repito lentamente las diferentes llamadas de ADO y las reemplazo con llamadas de Linq2SQL hasta que toda la aplicación utiliza Linq2SQL. Luego me resulta más fácil transformar las llamadas ADO anteriores que expusieron y pasaron DataSets/DataTables a entidades más apropiadas.

Otro enfoque (para soluciones pesados ​​DataSet/DataTable) es mantener el ADO llama en su lugar y en lugar de utilizar los métodos de extensión AsQueryable() y/o OfType<T>() para transformar el DS/Dt artículos en entidades apropiadas, a continuación, agregar estos cambios en una DAL más coherente