¿Existen buenas razones para no utilizar un ORM? [cerrado]

Durante mi aprendizaje, he utilizado NHibernate para algunos proyectos más pequeños que en su mayoría codifiqué y diseñé por mi cuenta. Ahora, antes de comenzar un proyecto más grande, surgió la discusión sobre cómo diseñar el acceso a los datos y si usar o no una capa ORM. Como todavía estoy en mi aprendizaje y todavía me considero un principiante en programación empresarial, realmente no intenté presionar en mi opinión, que es que usar un mapeador relacional de objetos en la base de datos puede facilitar bastante el desarrollo. Los otros programadores del equipo de desarrollo tienen mucha más experiencia que yo, así que creo que haré lo que me digan. :-)

Sin embargo, no entiendo completamente dos de las principales razones para no usar NHibernate o un proyecto similar:

1. Uno puede simplemente construir sus propios objetos de acceso a datos con consultas SQL y copiar esas consultas fuera de Microsoft SQL Server Management Studio.
2. Depurar un ORM puede resultar complicado.

Entonces, por supuesto, podría simplemente construir mi capa de acceso a datos con muchos SELECTs, etc., pero aquí pierdo la ventaja de las uniones automáticas, las clases de proxy de carga diferida y un menor esfuerzo de mantenimiento si una tabla obtiene una nueva columna o una columna obtiene renombrado. (Actualización de numerosos SELECT, INSERTy UPDATEconsultas frente a la actualización de la configuración de mapeo y posiblemente refactorización las clases de negocios y dtos.)

Además, al usar NHibernate puede encontrarse con problemas imprevistos si no conoce muy bien el marco. Eso podría ser, por ejemplo, confiar en Table.hbm.xml donde establece la longitud de una cadena para que se valide automáticamente. Sin embargo, también puedo imaginar errores similares en una capa de acceso a datos basada en consultas SqlConnection "simple".

Finalmente, ¿son esos argumentos mencionados anteriormente realmente una buena razón para no utilizar un ORM para una aplicación empresarial basada en bases de datos no trivial? ¿Hay probablemente otros argumentos que ellos / yo podría haber pasado por alto?

(Probablemente debería agregar que creo que esta es como la primera aplicación "grande" basada en .NET / C # que requerirá trabajo en equipo. Las buenas prácticas, que se consideran bastante normales en Stack Overflow, como las pruebas unitarias o la integración continua, no -existente aquí hasta ahora.)

Ha habido una explosión de crecimiento con los ORM en los últimos años y es posible que sus compañeros de trabajo más experimentados sigan pensando en la mentalidad de que "todas las llamadas a la base de datos deben realizarse a través de un procedimiento almacenado".

¿Por qué un ORM haría las cosas más difíciles de depurar? Obtendrá el mismo resultado ya sea que provenga de un proceso almacenado o del ORM.

Supongo que el único detrimento real que se me ocurre con un ORM es que el modelo de seguridad es un poco menos flexible.

EDITAR: Acabo de volver a leer su pregunta y parece que están copiando y pegando las consultas en sql en línea. Esto hace que el modelo de seguridad sea el mismo que un ORM, por lo que no habría absolutamente ninguna ventaja sobre este enfoque sobre un ORM. Si utilizan consultas no parametrizadas, en realidad sería un riesgo de seguridad.

La respuesta corta es sí, hay muy buenas razones. De hecho, hay casos en los que simplemente no puede utilizar 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. 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 proporcionan 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 donde tiene una aplicación con una arquitectura de modelo de objetos sólida y una base de datos que funciona 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 hará una gran diferencia en 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 Patterns of Enterprise Application Architecture 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 funcionalmente orientada (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 de desarrollo y prueba bastante sustancial, y ahorra tener que migrar datos a un nuevo modelo de base de datos. A menudo es una buena manera de envolver capas de Java alrededor de bases de código PL / SQL heredadas, o reorientar 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 en 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 "lo 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 donde 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 propia 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 proporcionará necesariamente ventajas 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:

1. Probando tu código
2. Manteniendo su código

Las soluciones a estos son:

1. Haga que su código sea comprobable (utilizando principios SOLID )
2. Escriba pruebas automatizadas para la mayor cantidad de código posible
3. 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:

1. Está estrictamente prohibido por la política de la empresa (en cuyo caso iría a trabajar a otro lugar)
2. El proyecto es extremadamente intensivo en datos y el uso de soluciones específicas de proveedores (como BulkInsert) tiene más sentido.

Los rechazos habituales sobre los ORM (NHibernate en particular) son:

1. Velocidad

   No hay ninguna razón por la cual 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.

2. Complejidad

   Con respecto a la complejidad, usar un ORM significa menos código, lo que generalmente significa menos complejidad. Muchas personas que usan 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, peor aún, 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 donde se encuentran 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 de (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?)

Existe una amplia gama de problemas comunes para los cuales las herramientas ORM como Hibernate son un regalo de Dios, y algunos donde son un obstáculo. No sé lo suficiente sobre su proyecto para saber cuál es.

Uno de los puntos fuertes de Hibernate es que puede decir las cosas solo 3 veces: cada propiedad se menciona en la clase, el archivo .hbm.xml y la base de datos. Con las consultas SQL, sus propiedades están en la clase, la base de datos, las sentencias de selección, las sentencias de inserción, las sentencias de actualización, las sentencias de eliminación y todo el código de clasificación y desorganización que respalda sus consultas de SQL. Esto puede complicarse rápidamente. Por otro lado, sabes cómo funciona. Puedes depurarlo. Todo está ahí en su propia capa de persistencia, no enterrado en las entrañas de una herramienta de terceros.

Hibernate podría ser un ejemplo de la Ley de abstracciones con fugas de Spolsky. Salga un poco de los caminos trillados y necesita conocer el funcionamiento interno profundo de la herramienta. Puede ser muy molesto cuando sabe que podría haber arreglado el SQL en minutos, pero en su lugar está pasando horas tratando de engatusar su maldita herramienta para que genere un SQL razonable. La depuración es a veces una pesadilla, pero es difícil convencer a las personas que no han estado allí.

EDITAR: Es posible que desee buscar en iBatis.NET si no van a cambiar con NHibernate y quieren controlar sus consultas SQL.

EDICIÓN 2: Sin embargo, aquí está la gran bandera roja: "Las buenas prácticas, que se consideran bastante normales en Stack Overflow, como las pruebas unitarias o la integración continua, no existen aquí hasta ahora". Entonces, estos desarrolladores "experimentados", ¿qué experiencia tienen en el desarrollo? ¿Su seguridad laboral? Parece que podría estar entre personas que no están particularmente interesadas en el campo, así que no deje que maten su interés. Necesitas ser el equilibrio. Comenzar una pelea.

Trabajé en un proyecto donde no usar un ORM fue muy exitoso. Fue un proyecto que

1. Tenía que ser horizontalmente escalable desde el principio
2. Tuvo que desarrollarse rápidamente
3. Tenía un modelo de dominio relativamente simple

El tiempo que habría llevado hacer que NHibernate funcionara en una estructura particionada horizontalmente habría sido mucho más largo que el tiempo que llevó desarrollar un mapeador de datos súper simple que fuera consciente de nuestro esquema de particionamiento ...

Entonces, en el 90% de los proyectos en los que he trabajado un ORM ha sido una ayuda invaluable. Pero hay algunas circunstancias muy específicas en las que puedo ver que no usar un ORM es lo mejor.

En primer lugar, permítame decirle que los ORM pueden facilitar su vida de desarrollo si se integran correctamente, pero hay algunos problemas en los que el ORM puede impedirle alcanzar los requisitos y objetivos establecidos.

He descubierto que al diseñar sistemas que tienen grandes requisitos de rendimiento, a menudo me encuentro con el desafío de encontrar formas de hacer que el sistema sea más eficaz. Muchas veces, termino con una solución que tiene un alto perfil de rendimiento de escritura (lo que significa que escribimos datos mucho más de lo que leemos datos). En estos casos, quiero aprovechar las facilidades que me ofrece la plataforma de base de datos para alcanzar nuestros objetivos de rendimiento (es OLTP, no OLAP). Entonces, si estoy usando SQL Server y sé que tengo muchos datos para escribir, ¿por qué no usaría una inserción masiva ... bueno, como ya habrá descubierto, la mayoría de los ORMS (no sé si incluso uno solo lo tiene) no tiene la capacidad de aprovechar las ventajas específicas de la plataforma, como la inserción a granel.

Debe saber que puede combinar las técnicas ORM y no ORM. Acabo de descubrir que hay un puñado de casos extremos en los que los ORM no pueden satisfacer sus requisitos y debe solucionarlos para esos casos.

Cuando necesite actualizar 50000000 registros. Pon una bandera o lo que sea.

Intente hacer esto usando un ORM sin llamar a un procedimiento almacenado o comandos SQL nativos.

Actualización 1: intente también recuperar un registro con solo algunos de sus campos. (Cuando tienes una mesa muy "ancha"). O un resultado escalar. Los ORM también apestan en esto.

ACTUALIZACIÓN 2 : Parece que EF 5.0 beta promete actualizaciones por lotes, pero esta es una noticia muy importante (2012, enero)

Para una aplicación empresarial basada en una base de datos no trivial, realmente no hay justificación para no usar un ORM.

Características aparte:

• Al no utilizar un ORM, está resolviendo un problema que ya ha sido resuelto repetidamente por grandes comunidades o empresas con importantes recursos.
• Al utilizar un ORM, la pieza central de su capa de acceso a datos se beneficia de los esfuerzos de depuración de esa comunidad o empresa.

Para poner algo de perspectiva en el argumento, considere las ventajas de usar ADO.NET frente a escribir el código para analizar el flujo de datos tabulares uno mismo.

He visto que la ignorancia de cómo usar un ORM justifica el desdén de un desarrollador por los ORM. Por ejemplo: carga ansiosa (algo que noté que no mencionaste). Imagine que desea recuperar a un cliente y todos sus pedidos, y todos los elementos de detalle del pedido. Si confía únicamente en la carga diferida, se alejará de su experiencia con ORM con la opinión: "Los ORM son lentos". Si aprende a usar la carga ansiosa, lo hará en 2 minutos con 5 líneas de código, lo que sus colegas tardarán medio día en implementar: una consulta a la base de datos y vincular los resultados a una jerarquía de objetos. Otro ejemplo sería el dolor de escribir consultas SQL manualmente para implementar la paginación.

La posible excepción al uso de un ORM sería si esa aplicación fuera un marco ORM diseñado para aplicar abstracciones de lógica empresarial especializadas y diseñado para ser reutilizado en múltiples proyectos. Sin embargo, incluso si ese fuera el caso, obtendría una adopción más rápida mejorando un ORM existente con esas abstracciones.

No dejes que la experiencia de los miembros senior de tu equipo te arrastre en la dirección opuesta a la evolución de la informática. Me he desarrollado profesionalmente desde hace 23 años, y una de las constantes es el desdén por lo nuevo por parte de la vieja escuela. Los ORM son para SQL como el lenguaje C para ensamblar, y puede apostar que los equivalentes a C ++ y C # están en camino. Una línea de código de la nueva escuela equivale a 20 líneas de la vieja escuela.

Creo que tal vez cuando trabaje en sistemas más grandes, pueda usar una herramienta generadora de código como CodeSmith en lugar de un ORM ... Recientemente encontré esto: Cooperator Framework que genera procedimientos almacenados de SQL Server y también genera sus entidades comerciales, mapeadores, puertas de enlace, lazyload y todas esas cosas en C # ... compruébalo ... fue escrito por un equipo aquí en Argentina ...

Creo que está en el medio entre codificar toda la capa de acceso a datos y usar un ORM ...

Personalmente, me he opuesto (hasta hace poco) a usar un ORM, y solía arreglármelas escribiendo una capa de acceso a datos que encapsula todos los comandos SQL. La principal objeción a los ORM era que no confiaba en la implementación de ORM para escribir exactamente el SQL correcto. Y, a juzgar por los ORM que solía ver (principalmente bibliotecas PHP), creo que tenía toda la razón.

Ahora, la mayor parte de mi desarrollo web está usando Django, y encontré el ORM incluido realmente conveniente, y dado que el modelo de datos se expresa primero en sus términos y solo después en SQL, funciona perfectamente para mis necesidades. Estoy seguro de que no sería demasiado difícil superarlo y necesitaría complementarlo con SQL escrito a mano; pero para CRUD el acceso es más que suficiente.

No sé nada de NHibernate; pero supongo que también es "suficientemente bueno" para la mayor parte de lo que necesitas. Pero si otros codificadores no confían en él; será el principal sospechoso de cada error relacionado con los datos, lo que hará que la verificación sea más tediosa.

Podría intentar introducirlo gradualmente en su lugar de trabajo, enfocándose primero en pequeñas aplicaciones 'obvias', como el simple acceso a datos. Después de un tiempo, es posible que se use en prototipos y es posible que no se reemplace ...

Si se trata de una base de datos OLAP (por ejemplo, datos estáticos de solo lectura utilizados para informes / análisis, etc.), la implementación de un marco ORM no es apropiada. En cambio, sería preferible utilizar la funcionalidad de acceso a datos nativa de la base de datos, como los procedimientos almacenados. Los ORM son más adecuados para sistemas transaccionales (OLTP).

Creo que hay muchas buenas razones para no usar un ORM. En primer lugar, soy un desarrollador de .NET y me gusta ceñirme a lo que el maravilloso marco .NET ya me ha proporcionado. Hace todo lo que posiblemente necesito. Al hacer esto, se mantiene con un enfoque más estándar y, por lo tanto, hay muchas más posibilidades de que cualquier otro desarrollador que trabaje en el mismo proyecto en el futuro pueda tomar lo que está allí y ejecutarlo. Las capacidades de acceso a datos que ya proporciona Microsoft son bastante amplias, no hay razón para descartarlas.

He sido desarrollador profesional durante 10 años, he dirigido varios proyectos de más de un millón de dólares con mucho éxito y nunca he escrito una aplicación que necesitara poder cambiar a cualquier base de datos. ¿Por qué querrías que un cliente hiciera esto? Planifique cuidadosamente, elija la base de datos adecuada para lo que necesita y cúmplala. Personalmente, SQL Server ha sido capaz de hacer todo lo que yo necesitaba hacer. Es fácil y funciona muy bien. Incluso hay una versión gratuita que admite hasta 10 GB de datos. Ah, y funciona de maravilla con .NET.

Recientemente tuve que empezar a trabajar en varios proyectos que utilizan un ORM como capa de datos. Creo que es malo, y algo extra que tuve que aprender a usar sin ningún motivo. En la increíblemente rara circunstancia de que el cliente tuviera que cambiar las bases de datos, podría haber reelaborado fácilmente toda la capa de datos en menos tiempo del que he pasado jugando con los proveedores de ORM.

Honestamente, creo que hay un uso real para un ORM: si está creando una aplicación como SAP que realmente necesita la capacidad de ejecutarse en varias bases de datos. De lo contrario, como proveedor de soluciones, les digo a mis clientes que esta aplicación está diseñada para ejecutarse en esta base de datos y así es como es. Una vez más, después de 10 años y un sinnúmero de aplicaciones, esto nunca ha sido un problema.

De lo contrario, creo que los ORM son para desarrolladores que no entienden que menos es más, y piensan que cuantas más herramientas de terceros usen en su aplicación, mejor será su aplicación. Dejaré este tipo de cosas a los fanáticos de los súper fanáticos mientras yo produzco mucho más software excelente que cualquier desarrollador puede utilizar y ser productivo de inmediato.

El rendimiento en tiempo de ejecución es el único inconveniente real en el que puedo pensar, pero creo que eso es más que una compensación justa por el tiempo que ORM le ahorra desarrollar / probar / etc. Y en la mayoría de los casos, debería poder localizar cuellos de botella de datos y alterar las estructuras de sus objetos para que sean más eficientes.

No he usado Hibernate antes, pero una cosa que he notado con algunas soluciones ORM "listas para usar" es la falta de flexibilidad. Estoy seguro de que esto depende de con cuál vayas y de lo que necesites hacer con él.

Hay dos aspectos de los ORM que son preocupantes. Primero, son códigos escritos por otra persona, a veces de código cerrado, a veces de código abierto pero de gran alcance. En segundo lugar, copian los datos.

El primer problema causa dos problemas. Estás confiando en el código de forasteros. Todos hacemos esto, pero la decisión de hacerlo no debe tomarse a la ligera. ¿Y si no hace lo que necesita? ¿Cuándo descubrirás esto? Vives dentro de la caja que tu ORM dibuja para ti.

El segundo problema es uno de compromiso de dos fases. La base de datos relacional se está copiando en un modelo de objetos. Cambias el modelo de objetos y se supone que actualiza la base de datos. Esta es una confirmación de dos fases y no es la cosa más fácil de depurar.

Sugiero esta lectura para obtener una lista de las desventajas de los ORM.

http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx

Por mi parte, he encontrado que los ORM son muy útiles para la mayoría de las aplicaciones que he escrito.

/ Asger

La experiencia que he tenido con Hibernate es que su semántica es sutil, y cuando hay problemas, es un poco difícil entender qué es lo que anda mal bajo el capó. Escuché de un amigo que a menudo uno comienza con Criteria, luego necesita un poco más de flexibilidad y necesita HQL, y luego se da cuenta de que, después de todo, se necesita SQL sin formato (por ejemplo, Hibernate no tiene la unión AFAIK).

También con ORM, la gente tiende fácilmente a abusar de las asignaciones / modelos existentes, lo que lleva a que haya un objeto con muchos atributos que no se inician. Entonces, después de la consulta, la transacción interna Hibernate realiza la búsqueda de datos adicionales, lo que conduce a una posible ralentización. También, lamentablemente, el objeto del modelo de hibernación a veces se filtra en la capa de arquitectura de vista y luego vemos LazyInitializationExceptions.

Para usar ORM, uno realmente debería entenderlo. Desafortunadamente, uno tiene la impresión de que es fácil mientras no lo es.

Para no ser una respuesta per se, quiero reformular una cita que escuché recientemente. "Un buen ORM es como un Yeti, todos hablan de uno pero nadie lo ve".

Siempre que pongo mis manos en un ORM, generalmente me encuentro luchando con los problemas / limitaciones de ese ORM. Al final, sí, hace lo que quiero y estaba escrito en algún lugar de esa pésima documentación, pero me encuentro perdiendo otra hora que nunca obtendré. Cualquiera que haya usado nhibernate, luego nhibernate fluido en postgresql entendería por lo que he pasado. La sensación constante de "este código no está bajo mi control" realmente apesta.

No señalo con el dedo ni digo que sean malos, pero comencé a pensar en lo que estoy regalando solo para automatizar CRUD en una sola expresión. Hoy en día creo que debería usar menos ORM, tal vez crear o encontrar una solución que permita las operaciones de base de datos como mínimo. Pero soy solo yo. Creo que algunas cosas están mal en este campo de ORM, pero no tengo la habilidad suficiente para expresarlo.

Creo que usar un ORM sigue siendo una buena idea. Sobre todo teniendo en cuenta la situación que le das. Parece que por su publicación tiene más experiencia en lo que respecta a las estrategias de acceso a la base de datos, y mencionaría el uso de un ORM.

No hay ningún argumento para el n. ° 1, ya que copiar y pegar consultas y codificar en texto no da flexibilidad, y para el n. ° 2, la mayoría de los orms ajustarán la excepción original, permitirán rastrear las consultas generadas, etc., por lo que la depuración tampoco es ciencia de cohetes.

En cuanto a la validación, el uso de un ORM también facilitará mucho el desarrollo de estrategias de validación, además de cualquier validación incorporada.

Escribir su propio marco puede ser laborioso y, a menudo, se pierden cosas.

EDITAR: Quería hacer un punto más. Si su empresa adopta una estrategia ORM, eso mejora aún más su valor, ya que desarrollará pautas y prácticas para usar e implementar y todos mejorarán aún más su conocimiento del marco elegido, mitigando uno de los problemas que mencionó. Además, aprenderá qué funciona y qué no cuando surgen situaciones y, al final, le ahorrará mucho tiempo y esfuerzo.

Cada ORM, incluso uno "bueno", viene cargado con un cierto número de suposiciones que están relacionadas con la mecánica subyacente que utiliza el software para pasar datos entre su capa de aplicación y su almacén de datos.

Descubrí que para aplicaciones moderadamente sofisticadas, trabajar alrededor de esas suposiciones generalmente me lleva más tiempo que simplemente escribir una solución más directa, como: consultar los datos e instanciar manualmente nuevas entidades.

En particular, es probable que tenga problemas tan pronto como emplee claves de varias columnas u otras relaciones moderadamente complejas que caen fuera del alcance de los ejemplos prácticos que su ORM le proporcionó cuando descargó el código.

Concedo que para ciertos tipos de aplicaciones, particularmente aquellas que tienen una gran cantidad de tablas de bases de datos, o tablas de bases de datos generadas dinámicamente, el proceso de magia automática de un ORM puede ser útil.

De lo contrario, al diablo con los ORM. Ahora los considero básicamente una moda pasajera.