Cambiar a ORM

Question

Estoy jugando con la idea de incorporar gradualmente un ORM en una aplicación que admito.La aplicación no está muy estructurada y no cuenta con pruebas unitarias.Por tanto, cualquier cambio será arriesgado.Obviamente me preocupa tener una razón suficientemente buena para cambiar.La idea es que habrá menos códigos repetitivos para el acceso a datos y habrá una mayor productividad.

¿Esto suena cierto con tus experiencias?
¿Es posible o incluso una buena idea implementarlo gradualmente?
¿Cuáles son las desventajas de un ORM?

Answer 1

Recomiendo encarecidamente obtener una copia del libro de Michael Feather. Trabajar eficazmente con código heredado (Por "Código heredado", Feathers se refiere a cualquier sistema que no esté adecuadamente cubierto por pruebas unitarias).Está lleno de buenas ideas que deberían ayudarle con la refactorización y la introducción gradual de las mejores prácticas.

Claro, podrías introducir gradualmente un ORM, usándolo inicialmente para acceder a algún subconjunto de tu modelo de dominio.Y sí, descubrí que el uso de un ORM acelera el tiempo de desarrollo; este es uno de los beneficios clave y ciertamente no extraño los días en los que solía crear laboriosamente capas de acceso a datos.

Desventajas de ORM: por experiencia, inevitablemente hay una pequeña curva de aprendizaje para familiarizarse con los conceptos, la configuración y las idiosincrasias de la solución ORM elegida.

Editar:nombre del autor corregido

Answer 2

El libro "Robert C Martin", que en realidad fue escrito por Michael Feathers ("¡El tío Bob" es, al parecer, una marca en estos días!) es imprescindible.

Es casi imposible (por no mencionar que requiere mucho tiempo) colocar pruebas unitarias en una aplicación que no se haya desarrollado con ellas.El código simplemente no será compatible.

Pero eso no es un problema.Refactorizar consiste en cambiar el diseño sin cambiar la función (espero no haber corrompido demasiado el significado allí) para que puedas trabajar de una manera mucho más amplia.

Comience con trozos grandes.Configure una ejecución repetible y capture lo que sucede como resultado esperado para ejecuciones posteriores.Ahora tienes tu aplicación, o al menos parte de ella, bajo prueba.No es una prueba muy buena ni completa, claro, pero es un comienzo y las cosas sólo pueden mejorar a partir de ahí.

Ahora puedes comenzar a refactorizar.Desea comenzar a extraer su código de acceso a datos para poder reemplazarlo con la funcionalidad ORM sin molestar demasiado.Pruebe con frecuencia:con las aplicaciones heredadas te sorprenderá lo que se estropea;la cohesión y el acoplamiento rara vez son lo que podrían ser.

También consideraría mirar el de Martin Fowler. Refactorización, que es, obviamente, el trabajo definitivo sobre el proceso.

Answer 3

Trabajo en una gran aplicación ASP.net donde recientemente comenzamos a usar NHibernate.En su lugar, movimos una gran cantidad de objetos de dominio que habíamos estado conservando manualmente a Sql Server y a NHibernate.Simplificó bastante las cosas y hizo que fuera mucho más fácil cambiarlas con el tiempo.Estamos contentos de haber realizado los cambios y de estar utilizando NHibernate cuando corresponda para gran parte de nuestro nuevo trabajo.

Answer 4

Escuché que TypeMock se usa a menudo para refactorizar código heredado.

Answer 5

Realmente creo que introducir ORM en una aplicación heredada genera problemas (y podría ser la misma cantidad de problemas que una reescritura completa).

Aparte de eso, ORM es un excelente camino a seguir y definitivamente debería considerarse.

Answer 6

La regla para la refactorización es.Hacer pruebas unitarias.

Entonces, tal vez primero deberías realizar algunas pruebas unitarias al menos para las cosas principales/centrales.

El ORM debe diseñarse para disminuir el código repetitivo.El tiempo/problema vs.El ROI para ser empresarial depende de usted estimarlo :)

Answer 7

A menos que su código ya esté diseñado para permitir el "intercambio en caliente" del backend de su capa de modelo, cambiarlo de cualquier manera siempre será extremadamente arriesgado.

Intentar construir una red de seguridad de pruebas unitarias en código con una arquitectura deficiente no garantizará el éxito, solo lo hará sentir más seguro al cambiarlo.

Por lo tanto, a menos que tenga un argumento comercial sólido para asumir los riesgos involucrados, probablemente sea mejor dejarlo como está.