Generadores de código vs.ORM vs.Procedimientos almacenados

Question

¿En qué dominios brilla o fracasa cada una de estas arquitecturas de software?

¿Qué requisitos clave le impulsarían a elegir uno sobre el otro?

Suponga que tiene desarrolladores disponibles que pueden hacer un buen código orientado a objetos, así como un buen desarrollo de bases de datos.

Además, evite las guerras santas :) las tres tecnologías tienen pros y contras, me interesa saber dónde es más apropiado usar cuál.

Answer 1

Cada una de estas herramientas proporciona diferentes capas de abstracción, junto con diferentes puntos para anular el comportamiento.Éstas son opciones de arquitectura, y todas las opciones de arquitectura dependen de compensaciones entre tecnología, control y organización, tanto de la aplicación en sí como del entorno donde se implementará.

• Si se trata de una cultura en la que los administradores de bases de datos 'manejan la batuta', entonces una arquitectura basada en procedimientos almacenados será más fácil de implementar.Por otro lado, puede resultar muy difícil gestionar y versionar los procedimientos almacenados.

• Los generadores de código brillan cuando se utilizan lenguajes de tipado estático, porque pueden detectar errores en tiempo de compilación en lugar de en tiempo de ejecución.

• Los ORM son ideales para herramientas de integración, en las que es posible que deba trabajar con diferentes RDBMS y esquemas de instalación a instalación.Cambie un mapa y su aplicación pasará de funcionar con PeopleSoft en Oracle a funcionar con Microsoft Dynamics en SQL Server.

He visto aplicaciones en las que se utiliza código generado para interactuar con procedimientos almacenados, porque los procedimientos almacenados se pueden modificar para sortear las limitaciones del generador de código.

En última instancia, la única respuesta correcta dependerá del problema que esté intentando resolver y del entorno donde se debe ejecutar la solución.Cualquier otra cosa es discutir la correcta pronunciación de 'patata'.

Answer 2

Agregaré mis dos centavos:

Procedimientos almacenados

• Se puede optimizar fácilmente
• Reglas comerciales fundamentales abstractas que mejoran la integridad de los datos
• Proporcionar un buen modelo de seguridad (no es necesario otorgar permisos de lectura o escritura a un usuario de base de datos frontal)
• Brilla cuando tienes muchas aplicaciones accediendo a los mismos datos

ORM

• Le permitirá concentrarse sólo en el dominio y tener un enfoque de desarrollo más "puro" orientado a objetos.
• Brilla cuando tu aplicación debe ser compatible con cross db
• Brilla cuando tu aplicación se basa principalmente en el comportamiento en lugar de en los datos

Generadores de código

• Proporcionarle beneficios similares a los ORM, con mayores costos de mantenimiento, pero con una mejor personalización.
• Generalmente son superiores a los ORM en el sentido de que los ORM tienden a intercambiar errores en tiempo de compilación por errores en tiempo de ejecución, lo que generalmente debe evitarse.

Answer 3

Estoy de acuerdo en que todo tiene pros y contras y mucho depende de tu arquitectura.Dicho esto, trato de utilizar ORM donde tenga sentido.Gran parte de la funcionalidad ya existe y, por lo general, ayudan a prevenir la inyección SQL (además, ayuda a evitar reinventar la rueda).

Consulte estas otras dos publicaciones sobre el tema (Procedimientos Dynamic SQL vs almacenados vs ORM) para obtener más información

SQL dinámico vs.procedimientos almacenados
Cual es mejor:¿Consultas ad hoc o procedimientos almacenados?

ORM vs.procedimientos almacenados
¿Por qué NHibernate genera SQL parametrizado tan rápido como un procedimiento almacenado?

Answer 4

Los ORM y los generadores de código están en un lado del campo y los procedimientos almacenados en el otro.Normalmente, es más fácil usar ORM y generadores de código en proyectos nuevos, porque puede adaptar el esquema de su base de datos para que coincida con el modelo de dominio que cree.Es mucho más difícil usarlos con proyectos heredados, porque una vez que el software se escribe con una mentalidad de "datos primero", es difícil envolverlo con un modelo de dominio.

Dicho esto, los tres enfoques tienen valor.Los procedimientos almacenados pueden ser más fáciles de optimizar, pero puede resultar tentador incluir en ellos una lógica empresarial que pueda repetirse en la propia aplicación.Los ORM funcionan bien si su esquema coincide con el concepto de ORM, pero puede ser difícil personalizarlos si no.Los generadores de código pueden ser un buen término medio, porque brindan algunos de los beneficios de un ORM pero permiten la personalización del código generado; sin embargo, si adquiere el hábito de alterar el código generado, tendrá dos problemas, porque Tendrás que modificarlo cada vez que lo vuelvas a generar.

No hay una respuesta verdadera, pero tiendo más hacia el lado ORM porque creo que tiene más sentido pensar con una mentalidad de objeto primero.

Answer 5

Procedimientos almacenados

• Ventajas: Encapsula el código de acceso a datos y es independiente de la aplicación.
• Contras: Puede ser específico de RDBMS y aumentar el tiempo de desarrollo.

ORM

Al menos algunos ORM permiten el mapeo de procedimientos almacenados

• Ventajas: Resume el código de acceso a datos y permite que los objetos de entidad se escriban de manera específica del dominio.
• Contras: Posible sobrecarga de rendimiento y capacidad de mapeo limitada

Codigo de GENERACION

• Ventajas: Se puede utilizar para generar código basado en proceso almacenado o un ORM o una combinación de ambos.
• Contras: Es posible que sea necesario mantener la capa del generador de código además de comprender el código generado.

Answer 6

Olvidaste una opción importante que merece una categoría propia:un marco de mapeo de datos híbrido como iBatis.

Estoy satisfecho con iBatis porque permite que su código OO siga siendo de naturaleza OO y su base de datos siga siendo de naturaleza relacional, y resuelve el desajuste de impedancia agregando una tercera abstracción (la capa de mapeo entre los objetos y las relaciones) que es responsable de mapear los dos, en lugar de intentar forzar el encaje de un paradigma en el otro.