Hay buenas razones para no utilizar un ORM? [cerrado]

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

Por ejemplo, trabajo para una gran institución financiera empresarial y tenemos que seguir muchas pautas de seguridad. Para cumplir con las normas y regulaciones que se nos imponen, la única manera de pasar 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 honestamente no lo es. herramienta / desarrollador puede insertar, seleccionar, actualizar o eliminar lo que él o ella quiere. Los procedimientos almacenados proporcionan mucha más seguridad, especialmente en entornos cuando se trata de datos de clientes. Creo que esta es la mayor razón a considerar. Seguridad.

El punto dulce de Orm

Los OR son útiles para automatizar el 95%+ de consultas donde son aplicables. Su fortaleza particular es cuando usted tiene una aplicación con una arquitectura de modelo de objeto fuerte y una base de datos que juega muy bien con ese modelo de objeto. Si está haciendo una nueva construcción y tiene fuertes habilidades de modelado en su equipo, probablemente obtendrá buenos resultados con un OR.

Es posible que tenga un puñado de consultas que se hacen mejor a mano. En este caso, no tenga miedo de 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á minoritario. Teniendo en cuenta que deberá probar su aplicación en cualquier plataforma en la que tenga la intención de soportarla, un poco de esfuerzo adicional de portabilidad para algunos procedimientos almacenados no hará mucha 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 trabajar alrededor de los límites de un OR.

He visto que el enfoque anterior funciona bien en un proyecto J2EE muy grande (100 años de personal).

Donde un OR puede no ser el mejor ajuste

En otros casos puede haber enfoques que se adapten mejor a la aplicación que un OR. Fowler Patrones de Arquitectura de Aplicaciones Empresariales tiene una sección sobre patrones de acceso a datos que hace un buen trabajo de catalogar varios enfoques a esto. Algunos ejemplos que he visto de situaciones donde un OR puede no ser aplicable son:

• En una aplicación con una importante base de código heredado de procedimientos almacenados, es posible que desee usar una capa de acceso a datos orientada funcionalmente (que no debe confundirse con lenguajes funcionales) para envolver los sprocs existentes. Esto reutiliza la capa de acceso a datos existente (y por lo tanto probada y depurada) y el diseño de la base de datos, que a menudo representa un esfuerzo considerable de desarrollo y pruebas, y ahorra tener que migrar datos a un nuevo modelo de base de datos. A menudo es una buena manera de envolver capas Java alrededor de bases de código PL/SQL heredadas, o redirigir aplicaciones VB, Powerbuilder o Delphi con interfaces web.

• Una variación es donde se hereda un modelo de datos que no es necesariamente adecuado para la asignación de O-R. Si (por ejemplo) está escribiendo una interfaz que rellena o extrae datos de un interfaz puede ser mejor trabajar directamente con la base de datos.

• Aplicaciones financieras u otros tipos de sistemas donde la integridad de los datos entre sistemas es importante, particularmente si está utilizando transacciones distribuidas complejas con confirmación en dos fases. Es posible que necesite microgestionar sus transacciones mejor de lo que un OR 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 es preferible trabajar a un nivel inferior.

• Situaciones en las que está utilizando un mecanismo de acceso a datos como ADO.Net eso es' lo suficientemente bueno ' y jugar muy bien con la plataforma es de mayor beneficio que el brings trae.

• A veces los datos son solo datos - puede ser el caso (por ejemplo) que su aplicación está trabajando con 'transacciones' en lugar de 'objetos' y que esta es una vista sensible del dominio. Un ejemplo de esto podría ser un paquete financiero donde tienes transacciones con campos de análisis configurables. Si bien la aplicación en sí puede estar construida en una plataforma O-O, no está vinculada a un solo modelo de dominio de negocio y puede no ser consciente 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 es consciente de un modelo de dominio de negocio como tal y un modelo de objeto (más allá de la estructura del libro mayor en sí) no es relevante para la aplicación.

En primer lugar - el uso de un OR 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 OR puede aumentar la velocidad de desarrollo, los mayores problemas que debe abordar son:

1. Probando su código
2. Mantener su código

Las soluciones a estos son:

1. Haga que su código sea comprobable (usando principios SÓLIDOS)
2. Escribir pruebas automatizadas para la mayor cantidad de código posible
3. Ejecute las pruebas automatizadas tan a menudo como sea posible

Llegando a su pregunta, las dos objeciones que usted lista parecen más ignorancia que cualquier otra cosa.

No poder escribir consultas SELECT a mano (que, supongo, es por lo que se necesita copiar y pegar) parece indicar que hay una necesidad urgente de algún entrenamiento SQL.

Hay dos razones por las que no usaría un OR:

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

Los rechazos habituales sobre OR (NHibernate en particular) son:

1. Velocidad

   No hay ninguna razón por la que usar un OR sea más lento que el acceso a Datos codificados a mano. De hecho, debido al almacenamiento en caché y las optimizaciones incorporadas, puede ser más rápido. Un buen OR producirá un conjunto repetible de consultas para las que puede optimizar su esquema. Un buen OR también permitirá la recuperación eficiente de los datos asociados utilizando varias estrategias de obtención.

2. Complejidad

   Con respecto a la complejidad, usar un OR 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). 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 OR es que las mismas personas que afirman que usar un OR será demasiado difícil/lento/lo que sea son las mismas personas que están más que felices usando Linq Para Sql o Conjuntos de Datos Escritos. Si bien 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 losMs de código abierto. Sin embargo, los frameworks para ambos Conjuntos de datos Escritos y para Linq A Sql siguen siendo enormemente complejos, y usarlos para ir demasiado lejos de (Table=Class) + (basic CRUD) es estúpidamente difícil.

Mi consejo es que si, al final del día, no puede obtener un OR, asegúrese de que su acceso a los datos esté separado del resto del código, y que sigues el consejo de la Banda de los Cuatro de codificar a una interfaz. Además, obtenga un marco de inyección de Dependencia para hacer el cableado.

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

Hay una amplia gama de problemas comunes para los cuales las herramientas OR como Hibernar son un envío de Dios, y algunos donde es un obstáculo. No se lo suficiente sobre tu proyecto para saber cual es.

Uno de los puntos fuertes de Hibernate es que puedes decir cosas solo 3 veces: cada propiedad se menciona en la clase, la .hbm.archivo xml, y la base de datos. Con las consultas SQL, sus propiedades están en la clase, la base de datos, las instrucciones select, las instrucciones insert, las instrucciones update, las instrucciones delete, y todo el código marshalling y unmarshalling que soporta sus consultas SQL! Esto puede complicarse rápidamente. Por otro lado, ya sabes cómo funciona. Puedes depurarlo. Está bien allí en su propia capa de persistencia, no enterrado en las entrañas de una herramienta de terceros.

Hibernar podría ser un ejemplo de la Ley de Spolsky de las Abstracciones Filtrantes. Salga un poco del camino trillado, y necesita conocer el funcionamiento interno profundo de la herramienta. Puede ser muy molesto cuando sepa que podría haber arreglado el SQL en minutos, pero en su lugar está gastando horas tratando de engatusar a su maldita herramienta para generar 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 mirar en iBatis.NET si no van a ser girados alrededor de NHibernate y quieren control sobre sus consultas SQL.

EDIT 2: Aquí está la gran bandera roja, sin embargo: "Buenas prácticas, que se ven como bonitas el desbordamiento normal en la pila, como las pruebas unitarias o la integración continua, no existen aquí hasta ahora."Entonces, estos desarrolladores "experimentados", ¿qué tienen experiencia en el desarrollo? ¿Su seguridad laboral? Suena como si estuvieras entre las personas que no están particularmente interesadas en el campo, así que no dejes que maten tu interés. Tienes que ser el equilibrio. Pelea.

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

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

El tiempo que le habría llevado a NHibernate trabajar en una estructura con particiones horizontales habría sido mucho más largo que el tiempo que le habría llevado desarrollar un datamapper súper simple que estuviera al tanto de nuestra partición Esquema...

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

Permítanme decir en primer lugar que losMs pueden hacer su vida de desarrollo más fácil si se integran correctamente, pero hay un puñado de problemas en los que el OR realmente puede evitar que alcance sus requisitos y objetivos declarados.

He encontrado que al diseñar sistemas que tienen requisitos de rendimiento pesados que a menudo me desafían a encontrar formas de hacer que el sistema sea más eficiente. 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). Así que si estoy usando SQL Server y sé que tengo una gran cantidad de datos para escribir, ¿por qué no utilizar una inserción masiva... bueno, como puede que ya hayas descubierto, la mayoría de losMS (no se si incluso uno solo lo hace) no tienen la capacidad de aprovechar las ventajas específicas de la plataforma como bulk insertar.

Debe saber que puede combinar las técnicas OR y no OR. Acabo de descubrir que hay un puñado de casos extremos donde losMs no pueden soportar sus requisitos y usted tiene que trabajar alrededor de ellos para esos casos.

Para una aplicación empresarial basada en bases de datos no triviales, realmente no hay justificación para no usar un OR.

Características aparte:

• Al no usar un OR, está resolviendo un problema que ya tiene resuelto repetidamente por grandes comunidades o empresas con recurso.
• Mediante el uso de un OR, 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 vs. escribir el código para analizar el flujo de datos tabulares uno mismo.

He visto que la ignorancia sobre cómo usar un OR justifica el desdén de un desarrollador por los OR, por ejemplo: carga ansiosa (algo que noté que no mencionaste). Imagine que desea recuperar a un cliente y todos sus pedidos, y para esos todos los artículos de detalle del pedido. Si solo confías en la carga lenta, te alejarás de tu experiencia OR con la opinión: "Los OR son lentos." Si aprenderás a usar eager loading, lo harás en 2 minutos con 5 líneas de código, lo que tus 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 manualmente consultas SQL para implementar paginación.

La posible excepción al uso de un OR sería si esa aplicación fuera un marco OR 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 al mejorar un OR existente con esas abstracciones.

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

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

Intente hacer esto usando un OR 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. ORs apestan en esto también.

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

Creo que tal vez cuando trabajas en sistemas más grandes puedes usar una herramienta generadora de código como CodeSmith en lugar de un OR... Recientemente encontré esto: Cooperator Framework que genera Procedimientos almacenados en SQL Server y también genera sus entidades de negocio, mapeadores, puertas de enlace, lazyload y todo eso en C#...compruébalo out...it fue escrito por un equipo aquí en Argentina...

Creo que está en el medio entre la codificación de toda la capa de acceso a datos y el uso de un OR...