Esta es el arreglo más acertada que te podemos dar, pero obsérvala detenidamente y analiza si se puede adaptar a tu trabajo.
Solución:
La respuesta corta es sí, hay muy buenas razones. De hecho, hay casos en los que simplemente no puede usar un ORM.
Por ejemplo, trabajo para una gran institución financiera empresarial y tenemos que seguir muchas pautas de seguridad. Para cumplir con las reglas y regulaciones que se nos imponen, la única forma de aprobar las auditorías es mantener el acceso a los datos dentro de los procedimientos almacenados. Ahora, algunos pueden decir que eso es simplemente estúpido, pero honestamente no lo es. El uso de una herramienta ORM significa que la herramienta / desarrollador puede insertar, seleccionar, actualizar o eliminar lo que quiera. Los procedimientos almacenados brindan mucha más seguridad, especialmente en entornos cuando se trata de datos de clientes. Creo que esta es la razón más importante a considerar. Seguridad.
El punto óptimo de los ORM
Los ORM son útiles para automatizar el 95% + de las consultas cuando son aplicables. Su fortaleza particular es cuando tiene una aplicación con una arquitectura de modelo de objetos sólida y una base de datos que funciona muy bien con ese modelo de objetos. Si está haciendo una nueva construcción y tiene fuertes habilidades de modelado en su equipo, probablemente obtendrá buenos resultados con un ORM.
Es posible que tenga un puñado de consultas que es mejor hacerlas a mano. En este caso, no tenga miedo de escribir algunos procedimientos almacenados para manejar esto. Incluso si tiene la intención de trasladar su aplicación a múltiples plataformas DBMS, el código dependiente de la base de datos será una minoría. Teniendo en cuenta que deberá probar su aplicación en cualquier plataforma en la que pretenda admitirla, un poco de esfuerzo adicional de portabilidad para algunos procedimientos almacenados no supondrá una gran diferencia para su TCO. Para una primera aproximación, 98% portátil es tan bueno como 100% portátil, y mucho mejor que las soluciones complicadas o de bajo rendimiento para sortear los límites de un ORM.
He visto que el enfoque anterior funciona bien en un proyecto J2EE muy grande (cientos de años-personal).
Donde un ORM puede no ser el mejor ajuste
En otros casos, puede haber enfoques que se adapten mejor a la aplicación que un ORM. Fowler’s Patrones de arquitectura de aplicaciones empresariales tiene una sección sobre patrones de acceso a datos que hace un buen trabajo al catalogar varios enfoques para esto. Algunos ejemplos que he visto de situaciones en las que un ORM puede no ser aplicable son:
-
En una aplicación con una base sustancial de código heredado de procedimientos almacenados, es posible que desee utilizar una capa de acceso a datos orientada funcionalmente (que no debe confundirse con lenguajes funcionales) para envolver los sprocs incumbentes. Esto reutiliza la capa de acceso a datos y el diseño de la base de datos existente (y por lo tanto probado y depurado), que a menudo representa un esfuerzo sustancial de desarrollo y prueba, y ahorra tener que migrar datos a un nuevo modelo de base de datos. A menudo es una buena manera de envolver las capas de Java alrededor de bases de código PL / SQL heredadas, o reorientar las aplicaciones de cliente rico VB, Powerbuilder o Delphi con interfaces web.
-
Una variación es cuando hereda un modelo de datos que no es necesariamente adecuado para el mapeo OR. Si (por ejemplo) está escribiendo una interfaz que completa o extrae datos de una interfaz externa, es mejor que trabaje directamente con la base de datos.
-
Aplicaciones financieras u otros tipos de sistemas en los que la integridad de los datos entre sistemas es importante, especialmente si utiliza transacciones distribuidas complejas con compromiso de dos fases. Es posible que necesite microgestionar sus transacciones mejor de lo que un ORM es capaz de soportar.
-
Aplicaciones de alto rendimiento en las que realmente desea ajustar el acceso a su base de datos. En este caso, puede ser preferible trabajar en un nivel inferior.
-
Situaciones en las que está utilizando un mecanismo de acceso a datos establecido como ADO.Net que es ‘suficientemente bueno’ y jugar bien con la plataforma es de mayor beneficio que el ORM.
-
A veces, los datos son solo datos; puede darse el caso (por ejemplo) de que su aplicación esté trabajando con ‘transacciones’ en lugar de ‘objetos’ y que esta sea una vista sensata del dominio. Un ejemplo de esto podría ser un paquete financiero en el que tiene transacciones con campos de análisis configurables. Si bien la aplicación en sí puede construirse en una plataforma OO, no está vinculada a un solo modelo de dominio comercial y es posible que no conozca mucho más que códigos GL, cuentas, tipos de documentos y media docena de campos de análisis. En este caso, la aplicación no conoce un modelo de dominio empresarial como tal y un modelo de objeto (más allá de la estructura del libro mayor) no es relevante para la aplicación.
En primer lugar, el uso de un ORM no hará que su código sea más fácil de probar, ni necesariamente proporcionará ninguna ventaja en un escenario de Integración Continua.
En mi experiencia, si bien el uso de un ORM puede aumentar la velocidad de desarrollo, los problemas más importantes que debe abordar son:
- Probando tu código
- Manteniendo su código
Las soluciones a estos son:
- Haga que su código sea comprobable (utilizando principios SOLID)
- Escriba pruebas automatizadas para la mayor cantidad de código posible
- Ejecute las pruebas automatizadas con la mayor frecuencia posible.
Al llegar a su pregunta, las dos objeciones que enumera parecen más ignorancia que cualquier otra cosa.
No poder escribir consultas SELECT a mano (que, supongo, es la razón por la que se necesita copiar y pegar) parece indicar que existe una necesidad urgente de capacitación en SQL.
Hay dos razones por las que no usaría un ORM:
- Está estrictamente prohibido por la política de la empresa (en cuyo caso iría a trabajar a otro lugar)
- El proyecto es extremadamente El uso intensivo de datos y el uso de soluciones específicas del proveedor (como BulkInsert) tiene más sentido.
Los rechazos habituales sobre los ORM (NHibernate en particular) son:
-
Velocidad
No hay ninguna razón por la que el uso de un ORM sea más lento que el acceso a datos codificado a mano. De hecho, debido al almacenamiento en caché y las optimizaciones integradas, puede ser más rápido. Un buen ORM producirá un conjunto repetible de consultas para las que puede optimizar su esquema. Un buen ORM también permitirá una recuperación eficiente de los datos asociados utilizando varias estrategias de búsqueda.
-
Complejidad
Con respecto a la complejidad, usar un ORM significa menos código, lo que generalmente significa menos complejidad. Muchas personas que utilizan acceso a datos escritos a mano (o generados por código) se encuentran escribiendo su propio marco sobre bibliotecas de acceso a datos de “bajo nivel” (como escribir métodos auxiliares para ADO.Net). Estos equivalen a una mayor complejidad y, lo que es peor, rara vez están bien documentados o bien probados.
Si está buscando específicamente NHibernate, entonces herramientas como Fluent NHibernate y Linq To NHibernate también suavizan la curva de aprendizaje.
Lo que me atrae de todo el debate de ORM es que las mismas personas que afirman que usar un ORM será demasiado difícil / lento / lo que sea son las mismas personas que están más que felices usando Linq To Sql o Typed Datasets. Si bien Linq To Sql es un gran paso en la dirección correcta, todavía está a años luz de algunos de los ORM de código abierto. Sin embargo, los marcos para los conjuntos de datos con tipo y para Linq To Sql siguen siendo enormemente complejos, y usarlos para ir demasiado lejos del (Table = Class) + (CRUD básico) es estúpidamente difícil.
Mi consejo es que si, al final del día, no puede obtener un ORM, asegúrese de que el acceso a sus datos esté separado del resto del código y de que siga los consejos de Gang Of Four de codificar para una interfaz. Además, obtenga un marco de inyección de dependencia para hacer el cableado.
(¿Qué tal eso para una perorata?)
Si para ti ha sido útil este artículo, te agradeceríamos que lo compartas con más juniors así nos ayudas a difundir este contenido.