c# - framework - ¿Hay buenas razones para no usar un ORM?

orm para c# (20)

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 a un lado:

Al no usar un ORM, está resolviendo un problema que ya ha sido resuelto repetidamente por grandes comunidades o compañías con recursos significativos.
Al usar un ORM, la pieza central de su capa de acceso a datos se beneficia de los esfuerzos de depuración de esa comunidad o compañía.

Para poner un poco de perspectiva en el argumento, considere las ventajas de usar ADO.NET vs. escribir el código para analizar el flujo de datos tabulares.

He visto la ignorancia de cómo usar un ORM justifica el desprecio de un desarrollador por los ORM Por ejemplo: carga ansiosa (algo que noté que no mencionó). Imagine que desea recuperar un cliente y todos sus pedidos, y para todos los artículos de detalles del pedido. Si solo confía en la carga diferida, se alejará de su experiencia en 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 tomarán medio día para implementar: una consulta a la base de datos y vinculando los resultados a una jerarquía de objetos. Otro ejemplo sería el dolor de escribir manualmente consultas SQL para implementar la búsqueda.

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 de negocios especializadas, y diseñado para ser reutilizado en múltiples proyectos. Incluso si ese fuera el caso, sin embargo, obtendría una adopción más rápida mejorando un ORM existente con esas abstracciones.

No permita que la experiencia de los miembros de su equipo senior lo arrastre en la dirección opuesta a la evolución de la informática. He estado desarrollando profesionalmente durante 23 años, y una de las constantes es el desdén por lo nuevo de la vieja escuela. Los ORM son para SQL, ya que el lenguaje C era ensamblado, y se puede apostar a 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.

Durante mi aprendizaje, he usado NHibernate para algunos proyectos más pequeños que codifiqué y diseñé principalmente 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 se usa 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é impulsar mi opinión, que es que usar un mapeador relacional de objetos en la base de datos puede facilitar bastante el desarrollo. Los otros codificadores en el equipo de desarrollo tienen mucha más experiencia que yo, así que creo que solo haré lo que digan. :-)

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

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.
La depuración de un ORM puede ser difícil.

Así que, por supuesto, podría construir mi capa de acceso a datos con muchos SELECT s, pero aquí echo de menos la ventaja de las uniones automáticas, las clases proxy de carga diferida y un menor esfuerzo de mantenimiento si una tabla obtiene una nueva columna o columna se renombra. (Actualizando numerosas consultas SELECT , INSERT y UPDATE frente a la actualización de la configuración de la asignación y posiblemente refactorizando las clases de negocio y los DTO).

Además, al usar NHibernate, puede encontrarse con problemas imprevistos si no conoce muy bien el marco. Eso podría ser, por ejemplo, confiando 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, ¿esos argumentos mencionados anteriormente son realmente una buena razón para no utilizar un ORM para una aplicación empresarial basada en una base de datos no trivial? ¿Hay probablemente otros argumentos que ellos / yo podríamos haber perdido?

(Probablemente debería añadir que creo que 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 pruebas unitarias o integración continua, no son -existente aquí hasta ahora.)

Creo que hay muchas buenas razones para no usar un ORM. En primer lugar, soy desarrollador .NET y me gusta mantenerme dentro de lo que el maravilloso framework .NET ya me ha proporcionado. Hace todo lo que posiblemente lo necesite. Al hacer esto, se queda 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 recoger lo que hay 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 liderado múltiples proyectos millonarios y muy exitosos, y nunca he escrito una aplicación que necesite poder cambiar a ninguna base de datos. ¿Por qué alguna vez querrías que un cliente hiciera esto? Planifique con cuidado, elija la base de datos correcta para lo que necesita y quédese con ella. Personalmente SQL Server ha sido capaz de hacer todo lo que he necesitado hacer. Es fácil y funciona muy bien. There''s even a free version that supports up to 10GB data. Oh, and it works awesome with .NET.

I have recently had to start working on several projects that use an ORM as the datalayer. I think it''s bad, and something extra I had to learn how to use for no reason whatsoever. In the insanely rare circumstance the customer did need to change databases, I could have easily reworked the entire datalayer in less time than I''ve spent fooling with the ORM providers.

Honestly I think there is one real use for an ORM: If you''re building an application like SAP that really does need the ability to run on multiple databases. Otherwise as a solution provider, I tell my clients this application is designed to run on this database and that is how it is. Once again, after 10 years and a countless number of applications, this has never been a problem.

Otherwise I think ORMs are for developers that don''t understand less is more, and think the more cool 3rd party tools they use in their app, the better their app will be. I''ll leave things like this to the die hard uber geeks while I crank out much more great software in the meantime that any developer can pick up and immediately be productive with.

Creo que tal vez cuando trabajas en sistemas más grandes puedes usar una herramienta de generación de código como CodeSmith en lugar de un ORM ... Hace poco encontré esto: Cooperator Framework que genera los procedimientos almacenados de SQL Server y también genera tus entidades comerciales, mapeadores, puertas de enlace, Lazyload y todo eso en C # ... compruébalo ... lo escribió un equipo aquí en Argentina ...

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

Cuando necesita actualizar 50000000 registros. Establecer 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 ORMs apestan en esto también.

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

El rendimiento en tiempo de ejecución es la única desventaja real que puedo pensar, pero creo que eso es más que una compensación justa por el momento en que ORM te ahorra desarrollo / prueba / etc. Y en la mayoría de los casos, debe poder localizar los cuellos de botella de datos y modificar las estructuras de los 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 lo que vaya y de lo que tenga que hacer.

En primer lugar, el uso de un ORM no facilitará la prueba de su código, 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 principales problemas que debe abordar son:

Probando tu código
Manteniendo tu código

Las soluciones a estos son:

Haga que su código sea comprobable (usando principios SOLID )
Escribir pruebas automatizadas para la mayor cantidad de código posible
Ejecute las pruebas automatizadas tan a menudo como sea posible

Al llegar a tu pregunta, las dos objeciones que mencionas parecen más como ignorancia que 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 hay 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 compañía (en cuyo caso iría a trabajar a otro lugar)
El proyecto requiere una gran cantidad de datos y el uso de soluciones específicas del proveedor (como BulkInsert) tiene más sentido.

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

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 en él, puede ser más rápido. Un buen ORM producirá un conjunto repetible de consultas para las cuales puede optimizar su esquema. Un buen ORM también permitirá la recuperación eficiente de los datos asociados mediante diversas 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 el acceso a datos escrito a mano (o generado por código) se encuentran escribiendo su propio marco de trabajo sobre bibliotecas de acceso a datos de "bajo nivel" (como escribir métodos de ayuda para ADO.Net). Esto equivale a una mayor complejidad y, lo que es peor, rara vez están bien documentados o bien probados.
Si está buscando específicamente NHibernate, herramientas como Fluent NHibernate y Linq To NHibernate también suavizan la curva de aprendizaje.

Lo que me atrapa de todo el debate ORM es que las mismas personas que afirman que usar un ORM serán demasiado duras / lentas / lo que sea que sean las mismas personas que están más que felices usando Linq To Sql o Typed Datasets. Mientras que el Linq To Sql es un gran paso en la dirección correcta, todavía está a años luz de donde están algunos de los ORM de código abierto. Sin embargo, los marcos tanto para los conjuntos de datos tipados como 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 puedes obtener un ORM, asegúrate de que tu acceso a los datos está separado del resto del código y de que sigues los consejos de la Gang Of Four para codificarlo. una interfaz. Además, obtenga un marco de Inyección de Dependencia para realizar el cableado.

(¿Cómo es eso de una diatriba?)

Ha habido una explosión de crecimiento con los ORM en los últimos años y sus compañeros de trabajo más experimentados aún pueden pensar en la mentalidad de "cada llamada a la base de datos debe 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 si proviene de un proceso almacenado o del ORM.

Supongo que el único detrimento real que puedo pensar 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 lo mismo que un ORM, por lo que no habría absolutamente ninguna ventaja sobre este enfoque sobre un ORM. Si están utilizando consultas sin parámetros, entonces sería un riesgo de seguridad.

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

El primer problema causa dos problemas. Usted confía en el código de los de afuera. Todos hacemos esto, pero la decisión de hacerlo no debe tomarse a la ligera. ¿Y qué pasa si no hace lo que necesita? ¿Cuándo descubrirás esto? Usted vive dentro de la caja que su ORM dibuja para usted.

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

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

Uno de los puntos fuertes de Hibernate es que puedes decir 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 declaraciones de selección, las instrucciones de inserción, las instrucciones de actualización, las instrucciones de eliminación y todos los códigos de ordenación y desmaquillaje que respaldan sus consultas SQL. Esto puede ser muy rápido. Por otro lado, ya sabes cómo funciona. Puedes depurarlo. Está todo ahí en tu propia capa de persistencia, no en las entrañas de una herramienta de terceros.

Hibernate podría ser un póster para la Ley de Extracciones Leaky de Spolsky. Olvídese un poco de la ruta establecida, y debe conocer el funcionamiento interno profundo de la herramienta. Puede ser muy molesto cuando sabes que podrías haber arreglado el SQL en minutos, pero en cambio estás pasando horas tratando de engatusar a tu herramienta de dang para que genere un SQL razonable. La depuración a veces es 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 dar la vuelta sobre NHibernate y quieren tener control sobre sus consultas SQL.

EDIT 2: Sin embargo, aquí está la gran bandera roja: "Las buenas prácticas, que se consideran bastante normales en , como las pruebas unitarias o la integración continua, no existen aquí hasta ahora". Entonces, estos desarrolladores "experimentados", ¿qué experimentan en el desarrollo? ¿Su seguridad laboral? Parece que podrías estar entre personas que no están particularmente interesadas en el tema, así que no dejes que maten tu interés. Debes ser el saldo. Comenzar una pelea.

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é está pasando mal bajo el capó. Un amigo me ha contado que a menudo uno comienza con Criteria, luego necesita un poco más de flexibilidad y necesita HQL, y luego nota que, después de todo, se necesita SQL sin procesar (por ejemplo, Hibernate no tiene unión AFAIK).

También con ORM, las personas tienden a abusar de mapeos / modelos existentes, lo que lleva a que haya un objeto con muchos atributos que no se inician. Por lo tanto, después de la consulta, dentro de la transacción, Hibernate realiza una búsqueda adicional de datos, lo que conduce a una posible desaceleración. También, lamentablemente, el objeto 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 que no lo es.

La respuesta corta es sí, hay muy buenas razones. De hecho, hay casos en los que simplemente no puede usar un ORM.

Por ejemplo, yo 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 manera de aprobar las auditorías es mantener el acceso a los datos dentro de los procedimientos almacenados. Ahora, algunos pueden decir que es simplemente estúpido, pero sinceramente 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 para considerar. Seguridad.

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

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

No apunto con los dedos o digo que son 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 operaciones de db como mínimo. Pero soy solo yo. Creo que algunas cosas están mal en esta arena ORM, pero no soy lo suficientemente hábil para expresar lo que no.

Permítanme primero decir que los ORM pueden facilitar su vida de desarrollo si se integran correctamente, pero hay un puñado de problemas en los que el ORM puede impedirle cumplir sus requisitos y objetivos establecidos.

He descubierto que al diseñar sistemas que tienen requisitos de alto rendimiento a menudo me veo en la necesidad de encontrar formas de mejorar el rendimiento del sistema. Muchas veces, termino con una solución que tiene un perfil de rendimiento de escritura pesado (lo que significa que estamos escribiendo datos mucho más de lo que estamos leyendo datos). En estos casos, quiero aprovechar las facilidades que la plataforma de base de datos me ofrece 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án descubierto, la mayoría de los ORMS (no sé si incluso uno solo lo hace) no tiene la capacidad de aprovechar las ventajas específicas de la plataforma como la inserción masiva.

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

Personalmente, me he opuesto (hasta hace poco) al uso de un ORM, y solía pasar escribiendo una capa de acceso a datos que encapsulaba todos los comandos SQL. La principal objeción a ORMs fue 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 de 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 complementar con SQL escritos a mano; pero para CRUD, el acceso es más que suficiente.

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

Podría tratar de introducirlo gradualmente en su lugar de trabajo, concentrarse primero en aplicaciones pequeñas "obvias", como el acceso simple a los datos. Después de un tiempo, podría usarse en prototipos, y podría no ser reemplazado ...

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 nativos de la base de datos, como los procedimientos almacenados. Los ORM son más adecuados para sistemas transaccionales (OLTP).

Sugiero esta lectura para una lista de los inconvenientes de los ORM.

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

¡Para mí, he encontrado que los ORM son muy útiles para la mayoría de las aplicaciones que he escrito!

/ Asger

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

Tenía que ser escalar horizontalmente desde el principio
Tuvo que ser desarrollado rápidamente
Tenía un modelo de dominio relativamente simple

El tiempo que hubiera llevado a NHibernate a trabajar en una estructura dividida horizontalmente hubiera sido mucho más largo que el tiempo que tardó en desarrollar un súper simple datamapper que conociera nuestro esquema de particiones ...

Entonces, en el 90% de los proyectos que he trabajado en 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.

El punto dulce de los ORM

Los ORM son útiles para automatizar el 95% + de las consultas donde son aplicables. Su punto fuerte es cuando tiene una aplicación con una sólida arquitectura de modelo de objetos 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 se hacen mejor a mano. En este caso, no tema escribir algunos procedimientos almacenados para manejar esto. Incluso si tiene la intención de portar su aplicación a través de 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 respaldarla, un poco de esfuerzo adicional de transferencia para algunos procedimientos almacenados no va a hacer una gran diferencia en su TCO. Para una primera aproximación, el 98% portátil es tan bueno como el 100% portátil, y mucho mejor que las soluciones intrincadas o de bajo rendimiento para trabajar alrededor de los límites de un ORM.

He visto que el enfoque anterior funciona bien en un proyecto J2EE muy grande (100 años de 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 donde un ORM puede no ser aplicable son:

En una aplicación con una base de código legado sustancial de procedimientos almacenados, es posible que desee utilizar una capa de acceso a datos orientada funcionalmente (que no se confunda con los idiomas funcionales) para ajustar los sprocs existentes. Esto reutiliza el diseño de la capa de acceso a datos existente (y por lo tanto probado y depurado) y de la base de datos, que a menudo representa un esfuerzo considerable de desarrollo y prueba, y ahorra al migrar datos a un nuevo modelo de base de datos. A menudo es una buena manera de envolver las capas de Java en torno a las bases de código PL / SQL heredadas, o reorientar las aplicaciones de Rich client VB, Powerbuilder o Delphi con interfaces web.
Una variación es donde hereda un modelo de datos que no necesariamente se adapta bien al mapeo OR. Si (por ejemplo) está escribiendo una interfaz que rellena o extrae datos de una interfaz extranjera, es mejor que trabaje directamente con la base de datos.
Aplicaciones financieras u otros tipos de sistemas donde la integridad de datos entre sistemas es importante, especialmente si está utilizando transacciones distribuidas complejas con confirmación 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 desea realmente ajustar su acceso a la base de datos. En este caso, puede ser preferible trabajar en un nivel inferior.
Las situaciones en las que está utilizando un mecanismo de acceso a datos incumbentes como ADO.Net que es "lo suficientemente bueno" y que juega muy bien con la plataforma es de mayor beneficio que el ORM.
A veces los datos son solo datos; puede ser el caso (por ejemplo) de que su aplicación esté trabajando con ''transacciones'' en lugar de ''objetos'' y que esta es 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í misma se puede construir en una plataforma OO, no está ligada a un solo modelo de dominio comercial y puede no estar al tanto de 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 tiene conocimiento de un modelo de dominio comercial como tal y un modelo de objeto (más allá de la propia estructura de contabilidad) no es relevante para la aplicación.

Every ORM, even a "good one", comes saddled with a certain number of assumptions that are related to the underlying mechanics that the software uses to pass data back and forth between your application layer and your data store.

I have found that for moderately sophisticated application, that working around those assumptions usually takes me more time than simply writing a more straightfoward solution such as: query the data, and manually instantiate new entities.

In particular, you are likely to run into hitches as soon as you employ multi-column keys or other moderately-complex relationships that fall just outside the scope of the handy examples that your ORM provided you when you downloaded the code.

Admito 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 auto-mágico de un ORM puede ser útil.

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

I think that using an ORM is still a good idea. Especially considering the situation you give. It sounds by your post you are the more experienced when it comes to the db access strategies, and I would bring up using an ORM.

There is no argument for #1 as copying and pasting queries and hardcoding in text gives no flexibility, and for #2 most orm''s will wrap the original exception, will allow tracing the queries generated, etc, so debugging isnt rocket science either.

As for validation, using an ORM will also usually allow much easier time developing validation strategies, on top of any built in validation.

Writing your own framework can be laborious, and often things get missed.

EDIT: I wanted to make one more point. If your company adopts an ORM strategy, that further enhances its value, as you will develop guidelines and practices for using and implementing and everyone will further enhance their knowledge of the framework chosen, mitigating one of the issues you brought up. Also, you will learn what works and what doesnt when situations arise, and in the end it will save lots of time and effort.