database - mapeo - orm para c#

ORM vs consulta de base de datos tradicional, ¿cuáles son sus campos? (9)

Como han dicho otros, puede escribir código ORM de bajo rendimiento y también puede escribir SQL de bajo rendimiento.

El uso de ORM no le exime de conocer su SQL y de entender cómo encaja una consulta. Si puede optimizar una consulta SQL, generalmente puede optimizar una consulta ORM. Por ejemplo, los criterios de Hibernate y las consultas HQL le permiten controlar qué asociaciones se unen para mejorar el rendimiento y evitar declaraciones de selección adicionales. Saber cómo crear un índice para mejorar su consulta más común puede hacer o deshacer el rendimiento de su aplicación.

Lo que ORM le compra es un acceso uniforme y mantenible a la base de datos. Proporcionan una capa adicional de verificación para garantizar que su código OO coincida lo más posible con el acceso a su base de datos, y le impida cometer ciertas clases de errores estúpidos, como escribir código que sea vulnerable a la inyección de SQL. Por supuesto, puede parametrizar sus propias consultas, pero ORM le compra esa ventaja sin tener que pensarlo.

ORM parece ser un modelo de rápido crecimiento, con sus pros y sus contras. De Ultra-Fast ASP.NET de Richard Kiessig ( http://www.amazon.com/Ultra-Fast-ASP-NET-Build-Ultra-Scalable-Server/dp/1430223839/ref=pd_bxgy_b_text_b ):

"Me encantan porque me permiten desarrollar sitios pequeños, con prueba de concepto, extremadamente rápido. Puedo dejar de lado gran parte del SQL y la complejidad relacionada que de otro modo necesitaría y centrarme en los objetos, la lógica de negocios y la presentación. Sin embargo, al mismo tiempo, tampoco me interesan por ellos porque, desafortunadamente, su rendimiento y escalabilidad suelen ser muy deficientes, incluso cuando están integrados con un sistema de almacenamiento en caché completo (el motivo se hace evidente cuando se da cuenta de eso cuando se realiza correctamente). Configurado, el propio SQL Server es en realidad solo un caché de big data

Mis preguntas son:

¿Cuál es tu comentario sobre la idea de Richard? ¿Estás de acuerdo con él o no? Si no, por favor diga por qué.
¿Cuáles son los mejores campos adecuados para ORM y consulta de base de datos tradicional? en otras palabras, dónde debería usar ORM y dónde debería usar la consulta de base de datos tradicional :), qué tipo / tamaño ... de aplicaciones debería elegir sin duda ORM / consulta de base de datos tradicional

Gracias por adelantado

Creo que este sitio utiliza Linq-to-SQL, y es un tráfico "bastante" alto ... Creo que el tiempo que ahorras al escribir el código de la placa de la caldera para acceder / insertar / actualizar elementos simples es invaluable, pero siempre existe el Opción de desplegar para llamar a un SPROC si tiene algo más complejo, en el que sabe que puede escribir algunos SQL gritando rápido directamente.

No creo que estas cosas tengan que ser mutuamente exclusivas; use las ventajas de ambas, y si hay secciones de su aplicación que comienzan a disminuir, entonces puede optimizar según lo necesite.

Estoy de acuerdo con la mayoría de los puntos ya mencionados aquí.

Los ORM no son nuevos en .NET, LLBLGen ha existido por mucho tiempo, los he estado usando por más de 5 años en .NET.

He visto un código de muy mal rendimiento escrito sin ORM (consultas de SQL ineficientes, índices incorrectos, llamadas de base de datos anidadas - ¡ay!) Y código malo escrito con ORM - estoy seguro de que también he contribuido con algunos de los códigos incorrectos :)

Lo que agregaría es que un ORM es generalmente una herramienta poderosa y que mejora la productividad que le permite dejar de preocuparse por el código de db de plomería para la mayoría de su aplicación y concentrarse en la aplicación en sí. Cuando comienza a tratar de escribir código complejo (por ejemplo, páginas de informes o IU complejas), debe comprender lo que sucede debajo del capó: la ignorancia puede ser muy costosa. Pero, usados correctamente, son inmensamente poderosos, y IMO no tendrá un efecto perjudicial en el rendimiento de sus aplicaciones. Por mi parte, no estaría contento con un proyecto que no usó un ORM.

La programación consiste en escribir software para uso comercial. Cuanto más podamos centrarnos en la lógica y presentación de negocios y menos con tecnicismos que solo importan en ciertos momentos (cuando el software se cae, cuando el software necesita una actualización, etc.), mejor.

Recientemente leí sobre las charlas de escalabilidad de un fundador de Reddit, desde here , y una línea de él que me llamó la atención fue esta:

"Tener que lidiar con las complejidades de las bases de datos relacionales (relaciones, uniones, restricciones) es cosa del pasado".

Por lo que he visto, el mantenimiento de un complejo esquema de base de datos, cuando se trata de escalabilidad, se convierte en un gran problema a medida que el sitio crece (agrega un campo, reasigna restricciones, vuelve a asignar claves externas, etc.). No estaba del todo claro para mí por qué es eso. Sin embargo, no están utilizando una base de datos NOSQL, están en Postgres.

Añadir a eso, aquí viene ORM, otra capa de abstracción. Simplifica la escritura de código, pero casi siempre en una penalización de rendimiento. Para mí, una biblioteca de abstracción de base de datos simple funcionará, al igual que las librerías AR ligeras, junto con las consultas de "texto sin formato" específicas de la base de datos. No puedo mostrarle ningún punto de referencia, pero con los ORM que he visto, la mayoría de ellos dice que "ORM a menudo puede ser lento".

Richard cubre ambos lados de la moneda, así que estoy de acuerdo con él.

En cuanto a los campos, realmente no entiendo el contexto de los "campos" sobre los que está preguntando.

No puedo aceptar la queja común sobre los ORM de que se desempeñen mal. He visto muchas aplicaciones de SQL plano hasta ahora. Si bien teóricamente es posible escribir SQL optimizado, en realidad, arruinan toda la ganancia de rendimiento al escribir la lógica empresarial no optimizada.

Cuando se usa SQL simple, la lógica de negocios se acopla en gran medida al modelo de db y las operaciones de base de datos y las optimizaciones están a la altura de la lógica de negocios. Debido a que no hay un modelo oo, no se pueden pasar estructuras de objetos enteras. He visto muchas aplicaciones que pasan las claves primarias y recuperan los datos de la base de datos en cada capa una y otra vez. He visto aplicaciones que acceden a la base de datos en bucles. Y así. El problema es: debido a que la lógica de negocios ya casi no se puede mantener, no hay espacio para más optimizaciones. A menudo, cuando intenta reutilizar al menos parte de su código, acepta que no está optimizado para cada caso. El rendimiento se vuelve malo por el diseño.

Un ORM generalmente no requiere que la lógica de negocios se preocupe demasiado por el acceso a los datos. Algunas optimizaciones se implementan en el ORM. Hay cachés y la capacidad de lotes. Estas optimizaciones automáticas (y dinámicas en tiempo de ejecución) no son perfectas, pero se desvinculan de la lógica empresarial. Por ejemplo, si un dato se usa condicionalmente, lo carga utilizando una carga perezosa a pedido (exactamente una vez). No necesitas hacer nada para que esto suceda.

Por otro lado, los ORM tienen una curva de aprendizaje empinada. No usaría un ORM para aplicaciones triviales, a menos que el ORM ya esté en uso por el mismo equipo.

Otra desventaja del ORM es (en realidad no del ORM en sí, sino del hecho de que trabajará con una base de datos relacional y un modelo de objeto), que el equipo debe ser fuerte en ambos mundos, tanto el relacional como el oo. .

Conclusión:

Los ORM son potentes para aplicaciones centradas en la lógica de negocios con estructuras de datos que son lo suficientemente complejas como para tener un modelo OO ventajoso.
Los ORM suelen tener una curva de aprendizaje (de alguna manera) pronunciada. Para aplicaciones pequeñas, podría ser demasiado caro.
Las aplicaciones basadas en estructuras de datos simples, que no tienen mucha lógica para administrarlas, son probablemente más fáciles y sencillas de escribir en sql simple.
Los equipos con un alto nivel de conocimiento de la base de datos y con poca experiencia en tecnologías oo probablemente serán más eficientes al usar sql simple. (Por supuesto, dependiendo de las aplicaciones que escriban, podría ser recomendable que el equipo cambie de enfoque)
Los equipos con un alto nivel de conocimiento y solo experiencia básica en bases de datos son probablemente más eficientes utilizando un ORM. (lo mismo aquí, dependiendo de las aplicaciones que escriban, podría ser recomendable que el equipo cambie de enfoque)

Nunca obtuve nada más que dolor y frustración de los paquetes de ORM. Si escribiera mi SQL de forma autógena, sí, afirmaría ser rápido y mi código sería lento :-) ¿Alguna vez has visto el SQL generado por un ORM? Apenas tiene PK-s, usa FK-s solo para interpretaciones equivocadas de "herencia" y si quiere hacer una búsqueda, descarga todo el conjunto de registros en ti y luego descarta el 90% de la misma :-))) Luego bloquea todo lo que está a la vista ya que tiene que tomar una carga de registros, ya que se remonta al procesamiento por lotes de IBM de 50 años.

Por un tiempo, pensé que el mayor problema con ORM era la división (no iba a tener un estándar en 50 años, cada año diferentes API, "modelo" de perdón :-) e ideologización (todo el mundo le vende una gran filosofía, siempre es mejor que todos de lo contrario, por supuesto :-) Entonces me di cuenta de que era realmente el amateurismo total la causa del desorden y todo lo demás es solo la consecuencia.

Entonces todo empezó a tener sentido. ORM nunca fue pensado para ser un actor o confiable, ni siquiera estaba en la lista :-) Era un juguete académico, "conceptual" desde el primer día, el premio de consolación para profesores enojó que todos sus trabajos de investigación "relacionales" en Prolog fue por el desagüe cuando IBM y Oracle comenzaron a vender esa cosa terrible de SQL y ganaron dinero :-)

Lo más cercano a confiar en uno fue LINQ, pero solo porque es posible y bastante fácil eliminar todo "seguimiento" y usarlo es solo como capa de deserialización para el código SQL normal. Luego leí que el objeto que está administrando la conexión puede desarrollar fallas espontáneas que suenan como GC prematuras, mientras que todavía tiene algunas cosas colgando. De ninguna manera iba a arriesgar mi cuello con eso después de eso - no, no mi cabeza :-)

Entonces, déjame hacer una lista:

Código totalmente descuidado - no va a sufrir errores y mal desempeño
- No va a tomar puntos muertos de las "transacciones" 10-100 veces más largas de ORM.
Reducción drástica de capacidades: el SQL tiene un gran poder expresivo en estos días
Atándote a la API marginal y descuidada (cada ORM apunta a secuestrar tu base de código)
- Las consultas de SQL son altamente portátiles y el conocimiento de SQL es totalmente portátil
Todavía tengo que saber SQL solo para limpiar el desorden de ORM de todos modos
Para la "prueba de concepto" simplemente puedo serializar a archivos binarios o XML
- no mucho más lento, cero bibliotecas de errores y una XPath puede seleccionar mejor de todos modos
- De hecho, he hecho sitios web con mucho tráfico, todos a partir de archivos XML.
- si realmente necesito un gráfico real, entonces no tengo uso para DB - nada real para consultar
- Puedo serializar un blob y volcarlo en SQL en como 3 líneas de código
Si alguien afirma que lo hace todo de DB a UI, mantenga su código base bloqueado :-)
- y haga una copia de seguridad de su base de datos de nómina - luego me agradecerá :-))
Las bases NoSQL son más honestas que ORM: "nos especializamos en persistencia"
- y tener una mejor calidad de código - no sorprendido en absoluto

Esa sería la lista corta :-) Por cierto, los motores SQL modernos de hoy en día hacen árboles e indexación espacial, por no mencionar la paginación sin perder un solo registro. Los ORM-s están realmente "resolviendo" problemas de hace 10 años y promoviendo el amateurismo. En ese sentido NoSQL, también conocido como documento.

ORM es bastante viejo, al menos en el mundo Java. Los principales problemas con ORM:

El modelo orientado a objetos y el modelo relacional son bastante diferentes.
SQL es un lenguaje de alto nivel para acceder a datos basados en álgebra relacional, diferente de cualquier lenguaje OO como C #, Java o Visual Basic.Net. Mezclar esos puede ser lo peor de dos mundos, en lugar de lo mejor.

Para obtener más información, busque en la web cosas como ''Desajuste de impedancia relacional entre objetos''

En cualquier caso, un buen marco ORM le ahorra bastante código de placa de caldera. Pero todavía necesita tener conocimientos de SQL, cómo configurar un buen modelo de base de datos SQL. Comience con la creación de un buen modelo de base de datos usando SQL, luego base su modelo OO en eso (no al revés)

Sin embargo, lo anterior solo es válido si realmente necesita utilizar una base de datos SQL. Recomiendo mirar en el movimiento NoSQL también. Hay cosas como Cassandra, Couch-db. Mientras buscaba en las soluciones .net, encontré esta pregunta de : https://.com/questions/1777103/what-nosql-solutions-are-out-there-for-net

ORM es mucho más antiguo que Java y .NET. El primero que conocí fue TopLink para Smalltalk. Es una idea tan antigua como los objetos persistentes.

Todos los marcos de "CRUD en la web" como Ruby on Rails, Grails, Django, etc. usan ORM para la persistencia porque todos suponen que está comenzando con un modelo de objeto de hoja limpia: no hay ningún esquema heredado para molestar. Comienzas con los objetos para modelar tu problema y generar la persistencia a partir de él.

A menudo funciona a la inversa con los sistemas heredados: el esquema es de larga duración y es posible que tenga o no objetos.

Es asombroso lo rápido que puede poner en marcha un prototipo con los marcos de trabajo de "CRUD en la web", pero no veo que se utilicen para desarrollar aplicaciones empresariales en grandes corporaciones. Tal vez eso es un prejuicio de Fortune 500.

Los administradores de bases de datos que conozco me dicen que no les gusta el SQL que generan los ORM porque a menudo es ineficiente. Todos desean una manera de sintonizarlo a mano.

Soy el autor del libro con el texto citado en la pregunta.

Permítame agregar enfáticamente que no estoy discutiendo contra el uso de objetos de negocios o la programación orientada a objetos.

Un problema que tengo con el ORM convencional, por ejemplo, LINQ to SQL o Entity Framework, es que a menudo lleva a los desarrolladores a hacer llamadas a la base de datos cuando ni siquiera se dan cuenta de que lo están haciendo. Esto, a su vez, es un asesino de rendimiento y escalabilidad.

Reviso muchos sitios web por problemas de rendimiento, y he encontrado que el volumen de datos de DB es una de las causas más comunes de problemas graves. Desafortunadamente, el ORM tiende a fomentar la inestabilidad, en espadas.

Las otras quejas que tengo sobre ORM incluyen:

No hay soporte para comandos por lotes
No hay soporte para múltiples conjuntos de resultados
No hay soporte para parámetros de tabla de valores
No hay soporte para llamadas asíncronas nativas (hacerlas desde un hilo en segundo plano no cuenta)
El soporte para SqlDependency y SqlCacheDependency es klunky si / cuando funciona en absoluto

No tengo ninguna objeción al uso de ORM tácticamente, para abordar problemas comerciales específicos. Pero me opongo a usarlo al azar, hasta el punto en que los desarrolladores hacen cosas como hacer exactamente la misma llamada a DB docenas de tiempo en la misma página, o emiten consultas sumamente caras sin considerar el almacenamiento en caché y las notificaciones de cambios, o ignoran totalmente las operaciones asíncronas cuando la escalabilidad es una preocupacion