Aplicaciones enriquecidas de dominio sin ORM

Soy relativamente nuevo en el mundo del desarrollo de software. Actualmente estoy en un proyecto, que es bastante grande, y es un código de OO decente, en su mayoría siguiendo los principios de diseño impulsado por el dominio. Sin embargo, a menudo mientras esto suena genial en teoría, prácticamente toda la Impedancia Relacional de Objetos es bastante mala, y significa que algunas partes del sistema son bastante lentas usando solo la capa ORM, a menos que escribamos consultas SQL optimizadas para cubrir esos casos. Además, a veces parece que estamos atascados tratando de ver si debemos modelar el dominio en función del desempeño de SQL frente a los principios de OO.Aplicaciones enriquecidas de dominio sin ORM

Esto me hace preguntar esto: ¿así se construyen la mayoría de las aplicaciones? Es decir, sí, OO está bien y bien, pero me resulta difícil creer que con todos los problemas asociados con este Desajuste relacional de objetos, ¿es esta la mejor manera de crear aplicaciones? El enfoque alternativo en el que puedo pensar es eliminar los ORM y simplemente tener un modelado de dominio, y escribir consultas SQL nativas directamente de forma uniforme. Me gustaría saber si en realidad hay sistemas de software de tamaño suficiente construidos de esta manera.

Lo siento si sueno n00bish, pero soy nuevo y me gustaría saber qué otros enfoques existen.

Fuente

2011-02-03 jeffreyveon

Uno puede usar ambos.

Para ser honesto, para simples modificaciones y vistas de registros únicos (incluida la visualización de entidades relacionadas), el ORM genera prácticamente el mismo código que escribiría a mano. Así que la ventaja es, por supuesto, que yo no tengo que escribirlo. Además, las modificaciones menores del esquema se manejan con gracia.

Para todo lo demás, SQL simple es el rey.

Soy de la opinión de que cualquier código que puede generarse, debe ser generada, con tal de que no produce una versión claramente deficiente. Creo que este es mi punto clave: Una cantidad significativa del código de la base de datos de una aplicación, puede ser procesada por un ORM y aún funcionar igual de bien como un código sql hecho a mano y escrito por un experto en bases de datos.

Fuente

2011-02-03 22:16:51 Ronnis

+1 por hecho de que las operaciones de una sola fila son más o menos las mismas, y el comentario que absolutamente nunca escucho, y comencé a pensar que era la única persona que lo creía, que cualquier código que pudiera generarse debería generarse. Sin embargo, no estoy de acuerdo en que el código generado por ORM también funcione, generalmente debido a los diseños de tabla bletcherous que se obtiene al modelar las ideas de OO en lugar de relacionales. Pero todavía vale la pena +1 –

+1 para la declaración "cualquier código que se pueda generar debe ser generado". Tal vez sufijo con "bien" - es decir, no solo genere código, genere _good_ código. Pero el principio se mantiene. – sfinnie

@Ken Downs, eso sería un problema con el diseño, y no con el propio ORM. Pero entiendo tu punto, y estoy totalmente de acuerdo. – Ronnis

No se disculpe por reconocer lo obvio. Aquellos con mucha más experiencia a menudo no reconocen lo que tienes: ORM es una mala ingeniería, exactamente por las razones que especifiques.

Pero no quiero caer en una diatriba. Los argumentos en contra del uso del rango de SQL incorporado desde el estilo, "no quiero que la basura en mi código" a, um, estilística, "SQL es feo". Pero funciona, es rápido y es una buena ingeniería.

Fuente

2011-02-03 18:29:26

habiendo trabajado tanto con ORM como con SQL + JDBC/ibatis, prefiero escribir mis consultas o incluso mejor, hacer que mi DBA optimice mis consultas, esos argumentos suenan más como excusas para no aprender (propper) SQL – Harima555

En realidad el uso de ORM no significa que no tenga control sobre la generación de SQL o que no tenga que tener un buen diseño de base de datos. Además, si necesita habilidades especiales para escribir consultas SQL, generalmente significa que su esquema de base de datos está roto. El esquema debe hacer que las consultas más frecuentes sean fáciles de escribir (y rápidas de ejecutar). Cuando uso ORM, creo mi esquema de tal manera que las consultas generadas por mi ORM son simples y rápidas. No es ciencia espacial. –

entonces si un esquema no se puede usar fácilmente desde un ORM, el esquema está roto ?, no estoy de acuerdo, puede haber una serie de razones por las cuales el esquema sería difícil de usar con un ORM, generalmente un esquema está diseñado para cumplir las necesidades del negocio, no las necesidades de rendimiento de un ORM, y si tengo que diseñar mi esquema para que mi ORM sea feliz y rápido, ahora está roto – Harima555

Aplicaciones enriquecidas de dominio sin ORM

Respuesta

Cuestiones relacionadas