oop - para - orm java

¿Cómo puedo diseñar una aplicación web Java sin un ORM y sin SQL incorporado

Question

EDITAR: Título original: Pregunta sobre el beneficio de usar un ORM.

Quiero usar un ORM para fines de aprendizaje y pruebo nhibernate. Estoy usando el tutorial y luego tengo un proyecto real. Puedo ir al "camino anterior" o usar un ORM. No estoy seguro de entender totalmente el beneficio. Por un lado, puedo crear mis abstracciones en el código de modo que pueda cambiar mis bases de datos y ser independiente de la base de datos. Por otro lado, parece que si realmente cambio las columnas de la base de datos, tengo que cambiar todo mi código.

¿Por qué no tendría mi aplicación sin el ORM, cambiaría mi base de datos y cambiaría mi código, en lugar de cambiar mi base de datos, orm y código? ¿Es que la estructura de la base de datos no cambia tanto?

Creo que hay beneficios reales porque los ORM son utilizados por muchos. Solo que no estoy seguro de obtenerlo todavía.

Gracias.

EDITAR: en el tutorial tienen muchos archivos que se utilizan para hacer que funcione el ORM

http://www.hibernate.org/362.html

En el caso de un cambio de aplicación, parece mucho trabajo adicional solo decir que tengo capas de abstracción "apropiadas". Como soy nuevo en esto, no parece tan fácil de mantener y de nuevo parece un trabajo extra, no menos.

EDITAR: Esta es una vieja pregunta a la que sigo volviendo. Lo que quiero ver es un ejemplo de diseñar correctamente una aplicación sin un ORM y sin utilizar SQL incorporado y sin usar .NET LINQ-to-SQL, sin ofender. Estoy en el mundo de Java en este momento, y estoy perdido en cómo proceder. Es una aplicación web. Sin primavera, sin otros marcos mundanos. JSP, JSTL, EL, HTML, JavaScript, CSS, Java, Tomcat. Espero no haber dejado nada. Y sí, sé que es una vieja pregunta. Aún es relevante.

Answer 1

¿Por qué, por qué, la industria está tan ligada a este desastre de un concepto? Ninguna de las respuestas anteriores aborda adecuadamente las preocupaciones de @ johnny. Son todas justificaciones a mano medio onduladas que se alejan bien de los problemas concretos que enfrentan los programadores de bases de datos.

La respuesta de @TXI es típica de las respuestas que recibo cuando hago la misma pregunta: separación de capas. ¿Qué se supone que significa eso? ¿Por qué quiero separar mis capas? O, más concretamente, ¿cómo me beneficia crear una capa adicional que sea diferente a la capa relacional y, sin embargo, se supone que es un mapeo canónico de esa capa?

Además, (el punto aún sin respuesta de @Jahhny) ¿cómo nos protege esto del cambio? Si la base de datos cambia, la capa ORM casi seguramente tendrá que seguir su ejemplo. De hecho, la práctica predeterminada de no modelar tablas de unión en el nivel de objeto lo empeora, porque cuando la tabla inevitablemente crece algunas columnas adicionales, no solo agrega algunos campos adicionales al modelo de objetos, sino que también cambia su topología y fuerza. un montón de código de reescritura! Este es un desastre para la gestión del cambio y es un ejemplo clásico de cómo una visión errónea de las relaciones (pensando que representan objetos) es un desastre para los tribunales. Esto simplemente no habría ocurrido si acaba de mapear la base de datos relacional directamente en nociones congruentes en el lenguaje de programación (piense LINQ-to-SQL, y no LINQ-to-EF).

La mayor pregunta sin respuesta en este espacio, el elefante en la habitación, es: ¿qué problema se supone que resolvería ORM? Y no diga "desajuste de la impedancia relacional del objeto". Eso es solo otro fob-off que agita la mano. Explica por qué hay una falta de correspondencia de impedancia y por qué debería ser la base de datos la que llega al idioma en lugar del idioma que va a la base de datos. Mi explicación es que la mayoría de los lenguajes de programación apestan al expresar y trabajar con datos relacionales, pero que esta es una realidad histórica que está comenzando a desvanecerse (LINQ-to-SQL fue el primer paso de bebé en esa dirección), no un principio fundamental en el que basar la arquitectura de sonido.

Hay una razón por la que los ORM se han vuelto tan complejos, con carga lenta, almacenamiento en caché, una serie desconcertante de persistencia y semántica de propiedad, etc. Y hay una razón por la cual, con todo este ruido extra en el teclado, fallan en resolver eficientemente problemas como "¿Qué pares de miembros comparten más de un grupo?" El modelo relacional se concibió en un momento en que los modelos de red y jerárquicos se doblaban sobre las rodillas bajo el peso de tales problemas; Fue un respiro de aire fresco. Ahora parece que todos anhelamos volver a nuestro viejo arenero lleno de orines, y creemos que hemos inventado algo nuevo (siempre que tengamos la nariz en alto).

(Espero totalmente ser votado negativamente en esta respuesta. Pero deje un comentario cuando lo haga. No me importa que me digan que estoy equivocado, siempre que sepa por qué).

EDITAR: Gracias @Chris por tomarse el tiempo para comentar. Me da algunos puntos concretos para abordar ... (Tenga en cuenta que aunque me dirijo a @Chris con frecuencia a continuación, no estoy tratando de hacerlo específicamente, sus respuestas son típicas de los tipos de comentarios que escucho todo el tiempo al discutir el Por lo tanto, espero que no tome mis críticas como una afrenta personal, no están destinadas de esa manera, y realmente aprecio el tiempo que tomó para responder.

En primer lugar, permítanme aclarar algunos conceptos erróneos evidentes en los comentarios y la respuesta de @ Chris.

1. No defiendo SQL sin formato en el código, por todas las razones obvias, y algunas no tan obvias (por ejemplo, SQL no es ni un álgebra ni un cálculo, lo que hace que la descomposición funcional sea prácticamente imposible).
2. No defiendo el diseño de aplicaciones monolíticas. Las capas son, en general, algo bueno.
3. No defiendo los modelos de objetos contaminantes con mucho ruido de línea como campos especiales, métodos y atributos. Francamente, sin embargo, este es un hombre de paja, ya que los modelos de dominio / objeto solo existen en el universo de ORM. Ahora, sé que LINQ-to-SQL tiene todas estas clases con muchos bits ruidosos, pero son solo plomería detrás de escena; no editas ese código, y generalmente ni siquiera deberías mirarlo.

Ahora algunas objeciones a las objeciones:

1. La afirmación de que las aplicaciones se pueden construir independientemente de la base de datos carece de fundamento. En general, los ORM son solo un mapeo canónico en la capa de datos (Tablas Foo y Bar se convierten en clases Foo y Bar, y la tabla FooBar se convierte en una especie de asunto tórrido entre las clases Foo y Bar). No hay mucho margen de maniobra en este mapeo, por lo que cualquier cambio en el modelo de datos requerirá casi con seguridad un cambio correspondiente en el modelo de objetos. Esto es algo bueno en mi opinión, ya que un objeto que diverge radicalmente del modelo de base de datos correspondiente no sería más que un dolor de cabeza adicional de mantenimiento para todos los interesados.
2. Una vez que se descarta la ilusión de que los ORM engendran independencia del modelo de datos, todas las protestas sobre los males del acoplamiento directo al modelo de datos se vuelven discutibles. Pero me gustaría seguir con esto un poco más allá que simplemente descartarlo. El acoplamiento es una característica esencial del diseño del sistema. En algún momento, se deben tomar decisiones y suposiciones. No puede programar todo usando una sola tabla de "Cosas". Debes decidir que tu dominio contiene ciertos conceptos específicos y luego crear esquemas y códigos que respeten esos conceptos, tratarlos como ciudadanos de primera clase y codificarlos. La idea de que las aplicaciones deberían ser independientes de la base de datos está equivocada. La base de datos es (o debería ser) la representación más pura del conocimiento de una empresa (sé que este no es siempre el caso, y lo abordaré más adelante). Acoplamiento a esta representación debería proporcionar la mayor garantía de resiliencia, ya que tal modelo de datos solo cambiará cuando la empresa misma experimente algún cambio intrínseco. En resumen, el acoplamiento a un esquema de base de datos bien diseñado es algo muy bueno.
3. La formación de capas no es un fin en sí mismo. Es bueno porque logra un objetivo específico. Los puntos anteriores muestran que las capas entre la base de datos y la aplicación en la forma en que lo hace ORM no son efectivas ni necesarias para lograr el objetivo real de la resiliencia al cambio. Esto se logra mediante un buen diseño de la base de datos.
4. @Chris afirma que dejar que la base de datos dicte cosas obstaculiza el diseño de OO. Esto es cierto, pero solo es interesante si el diseño OO es la mejor manera de modelar el conocimiento. La falla casi completa de OODBMS en el mercado sugiere que este no es el caso. El modelo relacional, con su fundamento de lógica de predicados, posee el mismo poder expresivo que el diseño OO sin incurrir en las complejidades teóricas de los modelos OO.
5. Las objeciones de @ Chris al modelo relacional sobre la base de que no resuelve los problemas de hoy (de ahí el movimiento NoSQL) está completamente fuera de lugar. NoSQL significa "No SQL", no "Ningún modelo relacional". Lamentablemente, incluso los defensores del movimiento NoSQL parecen ser bastante despistados en este sentido. SQL tiene fallas profundas, muchas de las cuales se pueden rastrear a su partida radical del modelo relacional. Decir que deberíamos abandonar el modelo relacional porque SQL apesta es un caso bastante descarado de tirar al bebé con el agua del baño.
6. La falta de uso de un ORM no triplica el esfuerzo de construir una aplicación. Este es un reclamo absurdo, e incluso @Chris parece estar sosteniendo la puerta trasera abierta con un cumplido indirecto a la alternativa del codegen. Las herramientas de Codegen como sqlmetal de LINQ-to-SQL son una solución perfecta para cualquiera que no esté comprometido con el dogma de que el modelo de datos de la aplicación tiene que ser absolutamente diferente al modelo de datos de la base de datos.

Mi propia experiencia con ORMs ha sido que funcionan muy bien en tutoriales y causan dolor y frustración sin fin en el mundo real. Con LINQ-to-SQL arreglando muchos de los problemas que motivaron los ORM en primer lugar, no veo ninguna razón para someterme a ese tipo de tortura.

Sigue existiendo un problema importante: el cultivo actual de bases de datos SQL no ofrece ningún grado significativo de control sobre la separación de capas físicas y lógicas. El mapeo de una tabla a cosas en el disco está en gran medida fijo y completamente bajo el control del SQL DBMS. Esto no era parte del plan para el modelo relacional, que separaba explícitamente ambos, y permitía la definición de una representación lógica consistente de los datos que podían almacenarse en el disco en una estructura completamente diferente a la sugerida por el modelo lógico. Por ejemplo, un sistema (o dba) sería libre de desnormalizar físicamente, por razones de rendimiento, un modelo lógico altamente normalizado. Debido a que los motores SQL no permiten esta separación de preocupaciones, es común desnormalizar o torturar el modelo lógico por pura necesidad. Como resultado, los modelos lógicos no siempre pueden ser exactamente como deberían, por lo que el ideal de usar la base de datos como la representación más pura del conocimiento no se puede realizar por completo. En la práctica, sin embargo, los diseñadores generalmente se apegan a un mapeo canónico de la base de datos al modelo de dominio de todos modos, porque cualquier otra cosa es demasiado dolorosa de mantener.

Answer 2

Antes de leer esto, a menudo me preguntaba si otros realmente se molestaban en comprender el impacto que una herramienta ORM tiene en un proyecto. @Evgeny, @Marcelo Cantos y @Jimmy B pusieron esto a descansar.

En resumen, están muertos con la mayoría de los problemas que rodean a las herramientas de ORM. Solo hay un par de ellos que no han cubierto o que no han cubierto lo suficiente.

Primero, el uso de un ORM no significa menos código. Puede significar menos SQL, pero ciertamente no significa menos código. En esta línea, el código generado por la herramienta puede ser incorrecto. Peor aún, compensar el código generado incorrecto es un ejercicio de frustración.

En segundo lugar, las herramientas ORM NO significan que no tenga que entender SQL. Para decirlo de otra manera, debes saber que SQL es un programador efectivo (hay excepciones como los chicos incrustados). Las consultas (tanto de tipo como de número) emitidas por estas herramientas simplemente no son lo suficientemente buenas desde una perspectiva de rendimiento o recursos. Si ya tiene que saber SQL, ¿por qué protegerse?

En tercer lugar, las herramientas ORM NO ahorran tiempo. Pasará tanto tiempo (si no más) superando su herramienta ORM de elección en el envío para ocuparse de cualquier aplicación de tamaño decente. Para colmo de males, cuando termines verás que la calidad de las consultas generalmente es peor que si lo hubieras hecho tú mismo. El punto es ORM = más tiempo dedicado al proyecto, peor resultado.

En cuarto lugar, la independencia DBMS es generalmente una pérdida de tiempo. La mayoría de las aplicaciones usarán exactamente un DBMS a lo largo de su vida; ya sea Oracle, SQL server, MySql, lo que sea. La aplicación estará mucho mejor y podrá aprovechar las características que ofrece DBMS. Ser independiente de DBMS significa que tendrá que limitarse a consultas secundarias.

En quinto lugar, no todo tiene que ser un objeto. Esto es algo importante a tener en cuenta. A menudo se nos pide que mostremos un conjunto particular de datos en una página. En la mayoría de los casos, esto significa unir datos de dos o más tablas. ¿Debe tu aplicación crear e instanciar todos esos objetos solo para mostrar algunos datos? ¿O es mejor simplemente ejecutar una consulta y emitir los datos directamente a la pantalla / navegador en el formato de su elección?

Los ORM agregan MUCHA sobrecarga incluso a las cosas más simples. La mayoría de los ORM generará múltiples consultas SQL para realizar incluso una simple ACTUALIZACIÓN en una tabla.

Sexto, y el tema más importante en mi mente: los ORM disminuyen su seguridad. Claro que puedes usar ORM''s con s''procs; pero la mayoría de las personas no. Casi todas las aplicaciones que he visto que aprovecharon un ORM expusieron la base de datos de tal manera que si el sitio se descifra la base de datos completa puede ser fácilmente asesinada o robada. Las herramientas ORM generan SQL sobre la marcha. Esto significa que necesitan acceso directo a la mesa. Esto significa que si su aplicación está comprometida, el pirata informático tendrá acceso directo a la tabla. Esto significa que ha eliminado efectivamente al menos una capa de seguridad de su aplicación.

Answer 3

Controlador principal: menos código general para administrar / mantener

Answer 4

El beneficio básico de usar herramientas ORM es facilitar el principio de separar la lógica comercial del acceso a los datos en una aplicación de varias capas. Si puede construir con éxito una capa de acceso a datos que responda a los cambios en la base de datos (al cambiar su asignación), hay menos código general para que tenga que rebuscar cuando se realizan cambios.

La separación de las capas suele ser el objetivo de las aplicaciones de 3 niveles o n niveles, y ORM es un buen método para hacerlo.

Answer 5

En mi experiencia con NHibernate, es un poco como Visual Basic: hace que los problemas fáciles sean realmente fáciles, pero también hace que todo sea más difícil que eso realmente difícil o incluso completamente imposible.

La idea básica es que ORM evita tener que escribir código de persistencia. Hay una gran cantidad de duplicaciones en dicho código, por lo que es muy tentador hacer que ese código sea genérico, en lugar de específico para una capa de negocios en particular, y reutilizarlo en todos los proyectos. Hasta aquí todo bien. Para las jerarquías simples de objetos y los requisitos comerciales, esto realmente funciona muy bien. Si su base de datos cambia, sí, debe cambiar los archivos de mapeo ORM, pero eso es bastante simple y solo tiene que hacer el cambio en un solo lugar, mucho más fácil que cambiar el código que accede a la base de datos.

El problema es que a medida que su base de datos y sus requisitos se hacen más complejos, a ORM le resulta cada vez más difícil mantenerse al día. Entonces el ORM se vuelve más y más complejo. También toma atajos, haciendo algunas cosas de manera ineficiente, porque simplemente no es lo suficientemente inteligente como para descubrir cómo hacerlo de manera eficiente en todos los casos. Además, debido a que la idea es que funciona de manera transparente, a menudo no se pueden ver estos problemas de rendimiento hasta que se vuelvan lo suficientemente graves como para afectar la experiencia del usuario. Un problema relacionado es que los errores son mucho más difíciles de encontrar, porque simplemente no sabes lo que está sucediendo dentro del ORM a menos que lo depure. (Sí, he tenido que pasar por el código NHibernate y no es un picnic!)

Así que empiezas a omitir el ORM para algunas cosas y en su lugar usas SQL directamente. Por supuesto, debe hacer que ese código funcione con el código que usa el ORM, que es más trabajo. Terminas escribiendo código para cargar y guardar algunos objetos manualmente y de alguna manera trabajar en el código ORM. Eventualmente, comienzas a preguntarte si el ORM está creando más trabajo para ti de lo que ahorra, sin mencionar el rendimiento y los dolores de cabeza de la caza de insectos.

Entonces, si estás escribiendo una aplicación muy simple, del tipo que encuentras en un tutorial, ORM hará un buen trabajo. Si es más complejo que eso, entonces creo que no vale la pena. Por supuesto, para una aplicación simple, la cantidad absoluta de tiempo ahorrado también será pequeña. Mi conclusión: simplemente no te molestes con ORM. ORM es el camino que lleva al lado oscuro.

Answer 6

La pregunta que no he visto a nadie abordar es qué problema o problemas deben resolver los ORM. El problema que se supone que los ORM deben resolver se relaciona con la desconexión entre el código del lado de la aplicación y la base de datos y la cantidad de tiempo que los desarrolladores pasan con las preocupaciones de la base de datos. La desconexión entre la base de datos y el código de la aplicación se refiere a tener que ejecutar la aplicación para darse cuenta de que el código escrito hace referencia a una columna no válida. Se supone que los ORM cierran esta brecha creando un modelo en el cual la base de datos, la aplicación y los datos se mueven juntos; Compilo, sé que el código no está sincronizado (siempre que mantenga mi Modelo actualizado).

Utilicé 3 ORM diferentes (EF, LINQ to SQL y N-Hibernate) en diversos proyectos de tamaño, desde pequeñas hasta grandes aplicaciones empresariales. Además, no soy ajeno a hacerlo con ADO.NET; DataReaders y mapeo de clases, DataSets y varias herramientas de generación. He visto implementaciones buenas y malas en los 3 ORM diferentes y sin método ORM. La mayoría de los problemas que he visto se remontan a antipatrones y no comprenden las limitaciones de un ORM particular. El siguiente artículo ( Antipatrones a evitar en aplicaciones N-Tier ) hace un buen trabajo al resaltar muchos de estos Antipatrones. Incluso los mejores arquitectos de software, desarrolladores y personas inteligentes han participado en su parte de Anti-Patrones antes de descubrir un patrón de diseño y / o el valor de ciertos principios de diseño que resolvieron el problema creado por el Anti-Pattern.

No conocer su herramienta es otro problema porque aquí es donde intervienen problemas de rendimiento. Está claro que muchos no están seguros de las diferencias de rendimiento entre Dynamic SQL y los procedimientos almacenados con respecto a la ejecución de la lógica de la base de datos, como las operaciones CRUD. Bueno, el veredicto está dentro y se ha comprobado que los comandos dinámicos son tan eficientes como sus homólogos de procedimiento almacenado. Ambos tienen ventajas y desventajas. La clave es saber cuáles son y seleccionar la opción adecuada para la situación.

Answer 7

Me doy cuenta de que esta pregunta fue publicada hace un tiempo, pero me he preguntado lo mismo que Johnny. He visto Hibernate utilizado en varios proyectos grandes por personas inteligentes, y en todos los casos, fue un desastre sin paliativos. En mi experiencia, el área más impactante e impactante de la mayoría de las aplicaciones empresariales se encuentra entre la capa de negocios y la capa de la base de datos. Esto es parte de por qué agregamos una capa de acceso a datos para tratar de encapsular las interacciones de la base de datos en fragmentos manejables.

Los argumentos más importantes que he visto para usar ORM son que "reducen el código escrito a mano" y proporcionan una capa de abstracción que separa la lógica empresarial del acceso a los datos. Afirmo que ninguno de estos son verdaderos en la práctica, excepto en casos muy simples.

Para hacer que Hibernate (y la mayoría de las demás herramientas ORM) funcionen, o bien creamos un archivo de mapeo hibernate que documenta todas las interacciones de bases de datos y objetos, o utilizamos anotaciones para documentar las mismas relaciones. En un caso, trasladamos nuestro código a un archivo de configuración xml que es más difícil de probar, pero no menos complejo. En el otro, distribuimos la lógica de cómo interactuar con la base de datos en todo el modelo de dominio. El punto es que, mientras escribimos menos "código" real, ¡moviendo el código a archivos de configuración o anotaciones! = "Menos código". Simplemente traslada la complejidad del código, donde podemos controlarlo directamente y mitigarlo, a una herramienta de terceros con mucho menos control.

La capa de abstracción de ORM que se supone separa la capa de negocio / dominio de la capa de la base de datos tiende a tener efectos más sutiles que contrarrestan esta "separación". ¿Cuántos proyectos ha visto donde la capa ORM afecta el diseño del modelo de objetos y / o la base de datos de una manera que se consideraría menos que ideal? Para utilizar una analogía de física pobre, suponga que su capa de negocio, capa de ORM y capa de base de datos tienen masa. La mera existencia de la capa ORM entre los otros tiende a ejercer una fuerza que cambia y deforma las otras capas. ¿Tuvo que introducir un objeto de clave principal que no encaja en su modelo de negocio porque la capa de ORM lo necesitaba? ¿Ha tenido que ajustar la estructura de su base de datos para acomodar un modelo de gráfico de objetos particularmente complejo porque la herramienta ORM no puede manejarlo de otra manera? Llevada al extremo, la presencia de la capa ORM puede deformar toda la perspectiva de cómo deberían funcionar las interacciones de la base de datos. En lugar de una capa de servicio que maneja gráficos de objetos persistentes, puede convertirse en la creación de objetos de capa de acceso a datos individuales para cada objeto de dominio, como si vivieran aislados. He visto todos estos escenarios en diversos grados. Tal vez es inexperiencia con el conjunto de herramientas ORM. Quizás es una mala estructura de base de datos. Lo dudo. Todo lo que he visto apunta a que la solución ORM es inadecuada.

Si acepta mi afirmación de que la capa de acceso a los datos es de complejidad, altamente propensa a los cuellos de botella de rendimiento, ¿por qué debería considerar agregar una herramienta que no logre sus objetivos de menos código y separación y, al mismo tiempo, afecte negativamente al estructura de las otras capas de mi aplicación?

Answer 8

Respondí completamente a la respuesta de @Marcelo Cantos, sin embargo resumiré los principales beneficios del uso de un ORM.

Ignorancia de persistencia (PI) y Diseño de unidad de dominio (DDD)

Un ORM se presta perfectamente a estos dos patrones de diseño en general. Para el diseño correcto orientado a objetos, trabajará con objetos jerárquicos y polimórficos para expresar cómo fluyen los datos dentro de su aplicación. Con un buen diseño, con frecuencia luchará por los objetos POCO (objetos simples antiguos C / C #, he visto otras definiciones de esta palabra) porque si tengo una Persona que tiene una Lista debería tener eso. No debería tener una DataTable de personas y una DataTable de direcciones que de alguna manera fuerce a trabajar con mi aplicación. Además de eso, no debería tener que atar toneladas de lógica específica de la base de datos a mis objetos, ¿por qué el campo FirstName de mi persona debe tener algo como [ColumnName("First_Name")] [Length(255)] [DataType(Types.Nvarchar)] o cualquier otro surtido de atributos o códigos locos que define cuántas bases de datos existen forzadas en mi diseño de dominio?

Código menos escrito a mano

Hay una reducción sustancial en el número de líneas de código escritas cuando elimina la necesidad de escribir una instrucción Seleccionar, Insertar, Actualizar y Eliminar para cada objeto en su aplicación para guardarla en la base de datos. Esto lo deja solo con la necesidad de escribir consultas que signifiquen algo. Además, muchos ORM (como NHibernate) incluirán un lenguaje que se superpone a SQL, que está más definido para interactuar y puede estar menos lleno sintácticamente de aros.

El momento en que esto aparece más completo es considerar una aplicación que tiene una UserTable que está vinculada a cada objeto y, por alguna razón, TIENE que cambiar el nombre o tipo de la clave principal. En este punto, es posible que tenga que modificar cada procedimiento almacenado en la base de datos donde con una solución ORM correctamente implementada, solo necesitará modificar algunas asignaciones de configuración (o posiblemente ninguna) y ya está hecho.

Answer 9

Si todo lo que obtengo de mi ORM es para salvarme de la necesidad de mantener los procedimientos almacenados, entonces eso es lo suficientemente bueno para mí.

Sin embargo, hay mucho más en el sentido de que un ORM nos permite liberarnos de los esquemas de bases de datos de agarre similares a los de los rehenes que imponen el diseño de nuestro código. Las cosas son mucho más simples cuando puedo modelar mi código exactamente como en el mundo real, y aún puedo hacer esto con un (buen) ORM que ayuda (y oculta) el mapeo de un db potencialmente legado antiestético con terribles convenciones de nomenclatura en una estructura que significa algo y no se preocupan por el código redundante como este en todas partes:

using (SqlWrapper sql = SqlWrapper.Create(WrapperConnectionType.ShopNet, "sStore_InsertUpdate_v4"))
            {
                sql.AddParameter("StoreId", StoreId);
                sql.AddParameter("StoreName", StoreName);
                sql.AddParameter("Region", Region);
                sql.AddParameter("PostCode", PostCode);
                sql.AddParameter("Tel", Tel);
                sql.AddParameter("Email", Email);
                sql.AddParameter("RegionId", RegionId);
                sql.AddParameter("MapImage", MapImage);
                sql.AddParameter("ShopImage", ShopImage);
                sql.AddParameter("Visible", Visible ? ''Y'' : ''N'');
                sql.AddParameter("TazEnabled", TasEnabled ? ''Y'' : ''N'');
                sql.AddParameter("Latitude", Latitude);
                sql.AddParameter("Longitude", Longitude);
                sql.AddParameter("StoreOpeningDate", OpeningDate);
                sql.AddParameter("CustomerNo", CustomerNo);
                sql.AddParameter("ReserveAtStoreEnabled", RasEnabled);
                sql.AddParameter("OpeningHoursId", OpeningHours.Id);
                sql.AddParameter("AddressLine1", AddressLine1);
                sql.AddParameter("AddressLine2", AddressLine2);
                sql.AddParameter("City", City);
                sql.AddParameter("District", District);
                sql.AddParameter("County", County);
                sql.AddParameter("CountryCode", CountryCode);
                sql.AddParameter("GoogleCategories", GoogleCategories);
                sql.AddParameter("GooglePlacesEnabled", GooglePlacesEnabled);
                sql.AddParameter("ManagerName", ManagerName);
                sql.AddParameter("MapZoomLevel", MapZoomLevel);
                sql.AddParameter("IpAddress", IpAddress);
                sql.AddParameter("FlibbleEnabled", FlibbleEnabled);
                sql.AddParameter("RegionalManager", RegionalManagerId);
                sql.AddParameter("ShutlLogin", ShutlLogin);
                sql.AddParameter("ShutlPassword", ShutlPassword);
                sql.Execute();
            }

y permite erradicar (pero no olvidar) este tipo de batallas:

System.IndexOutOfRangeException
at System.Data.SqlClient.SqlDataReader.GetOrdinal(String name)

El argumento para mí no tiene que ser más complicado que eso, obtengo un par de cosas buenas y algo horrible es quitado. Nuff dijo: ¡Siguiente!

Nadie está argumentando que un ORM es un reemplazo del 100% para todo lo tradicional. No será una gran herramienta para escribir informes complejos, para eso use SP y vistas, y use NHibernate para llamarlos de forma nativa y asignarlos automáticamente a sus entidades c #. Genial, sigue siendo todo el poder de SQL y no tiene un código de mapeo horrible.

Vete a la oscuridad, guardas de los años 0 y 1 y ven a la luz de sana c # weltanschauung.

Answer 10

Una ventaja que obtienes es que tu capa de datos está separada de la capa de objetos, así que cuando tienes múltiples aplicaciones / proyectos que dependen de esa capa, la cambias una vez en el ORM y todas las aplicaciones / proyectos que hacen referencia a la capa de objetos no tienen que cambio, mientras que sin él tendrías que hacer cambios en todos los proyectos.