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

Question

¿En qué dominios brillan o fallan cada una de estas arquitecturas de software?

¿Qué requisitos clave le pedirían que elija uno sobre el otro?

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

Además, por favor, evita las guerras santas :) las tres tecnologías tienen sus pros y sus contras, me interesa saber cuál es la más adecuada para usarlas.

Answer 1

Cada una de estas herramientas ofrece diferentes niveles de abstracción, junto con diferentes puntos para anular el comportamiento. Estas son opciones de arquitectura, y todas las opciones arquitectónicas dependen de las ventajas y desventajas entre la tecnología, el control y la organización, tanto de la aplicación como del entorno en el que se desplegará.

• Si usted está tratando con una cultura donde 'la batuta' DBA, a continuación, una arquitectura basada en procedimiento almacenado será más fácil de implementar. Por otro lado, puede ser muy difícil administrar y versionar procedimientos almacenados.

• Los generadores de códigos brillan cuando utiliza lenguajes estáticos, ya que puede detectar errores en tiempo de compilación en lugar de en tiempo de ejecución.

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

que he visto en aplicaciones donde el código generado se usa para interactuar con procedimientos almacenados, debido a que los procedimientos almacenados pueden ser ajustados para moverse por las limitaciones en el generador de código.

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

Answer 2

Estoy de acuerdo en que existen ventajas y desventajas para todo y que mucho depende de su arquitectura. Dicho esto, trato de usar ORM donde tiene sentido. Mucha de la funcionalidad ya está presente y generalmente ayudan a prevenir la inyección de SQL (además de ayudar a evitar reinventar la rueda).

Por favor, vea estos otros dos puestos en el tema (SQL dinámico vs procedimientos almacenados vs ORM) para obtener más información

SQL dinámico frente a los procedimientos almacenados
Which is better: Ad hoc queries, or stored procedures?

ORM vs almacenados procedimientos
Why is parameterized SQL generated by NHibernate just as fast as a stored procedure?

Answer 3

ORMs yc Los generadores de ode están en un lado del campo, y los procedimientos almacenados están en otro. Por lo general, es más fácil usar ORM y generadores de código en proyectos greenfield, ya que puede adaptar su esquema de base de datos para que coincida con el modelo de dominio que crea. Es mucho más difícil utilizarlos con proyectos heredados, porque una vez que el software está escrito con una mentalidad de "primero en datos", es difícil envolverlo con un modelo de dominio.

Habiendo dicho eso, los tres enfoques tienen valor. Los procedimientos almacenados pueden ser más fáciles de optimizar, pero puede ser tentador poner en ellos lógica comercial que pueda repetirse en la aplicación misma. Los ORM funcionan bien si su esquema coincide con el concepto de ORM, pero puede ser difícil de personalizar si no es así. Los generadores de código pueden ser un buen término medio, ya que proporcionan 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, entonces tiene dos problemas, porque usted tendrá que modificarlo cada vez que lo regenere.

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

Answer 4

procedimientos almacenados

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

ORM

Al menos algunos ORM permitir la asignación a los procedimientos almacenados

• Pros: resúmenes código de acceso de datos y permite a los objetos a ser escrito en
• Contras específicos de dominio manera entidad: Posible sobrecarga de rendimiento y capacidad de mapeo limitada

Generación de código

• Pros: se puede utilizar para generar código basado en proc almacenado o un ORM o una mezcla de ambos
• Contras: Código capa generador puede tienen que ser mantenidos además de comprensión código
generado

Answer 5

voy a añadir mi granito de arena:

Los procedimientos almacenados

• se pueden optimizar fácilmente
• reglas fundamentales del negocio abstracto, la mejora de la integridad de datos
• Proporcionar un modelo de buena seguridad (no es necesario otorgar permisos de lectura o escritura a un usuario db que mira hacia el frente)
• Brilla cuando tiene muchas aplicaciones ns que acceden a los mismos datos

ORM

• permiten concentrarse sólo en el dominio y tener un enfoque más objetivo "puro" orientada al desarrollo
• Shine cuando su aplicación debe ser db cruz
compatibles
• Shine cuando su aplicación se debe principalmente a la conducta en lugar de los datos

generadores de código

• que proporcionan beneficios similares como ORM, con mayores costos de mantenimiento, pero con mejor capacidad de personalización.
• son generalmente superiores a ORM en que los ORM tienden a comerciar errores en tiempo de compilación para los errores de ejecución, que en general es que hay que evitar

Answer 6

se le olvidó una opción importante que merece una categoría propia: un conjunto de datos híbridos marco de mapeo como iBatis.

He estado satisfecho con iBatis porque permite que su código OO permanezca OO en la naturaleza, y su base de datos sigue siendo de naturaleza relacional, y resuelve la falta de impedancia agregando una tercera abstracción (la capa de asignación entre los objetos y las relaciones) ese es el responsable de mapear los dos, en lugar de tratar de forzar el ajuste de un paradigma en el otro.