database - ventajas - ¿LINQ es un asignador relacional de objetos?

orm villano (6)

Creo que una buena prueba para determinar si una plataforma o bloque de código muestra las características de un O / RM es simplemente:

Con su sombrero de solución, ¿los desarrolladores (o su generador de códigos) tienen algún conocimiento directo y no abstraído de lo que hay dentro de la base de datos?

Con este criterio, la respuesta para diferentes implementaciones de LINQ puede ser

Sí, el conocimiento del esquema de la base de datos está contenido por completo en el LINQ utilizando su capa de código O / RM.

No, el conocimiento del esquema de la base de datos está disperso por toda la aplicación

Además, ampliaría esta caracterización a tres niveles simples de O / RM.

1. Abandono.
Es una aplicación pequeña con un par de desarrolladores y el modelo objeto / datos no es tan complejo y no cambia muy a menudo. El pequeño equipo de desarrollo puede mantenerse al tanto.
2. Pase el suyo en la capa de acceso a datos.
Con una refacturación manejable en una capa de acceso a datos, la funcionalidad O / RM deseada puede ser efectuada en una capa intermedia por el equipo de desarrollo relativamente pequeño. Lo suficiente para mantener a todo el equipo en la misma página.
3. Herramientas de definición / introducción de especificaciones de O / RM a nivel empresarial.
En cierto nivel de complejidad, la necesidad de mantener a todos los desarrolladores en la misma página simplemente inunda cualquier sobrecarga introducida por la formalidad. No es necesario reinventar la rueda en este nivel de complejidad. N-hibernate o el Marco de Entidad (bruto) V1.0 son ejemplos de esta escala.

Para una clasificación más rica, de la que tomé prestado y simplificado, vea la publicación clásica de Ted Neward en

http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx

donde clasifica los tratamientos O / RM (o abdicaciones) como

1. Abandono.
Los desarrolladores simplemente renuncian por completo a los objetos y vuelven a un modelo de programación que no crea el desajuste de impedancia de objeto / relación. Aunque es desagradable, en ciertos escenarios, un enfoque orientado a objetos genera más sobrecarga de la que ahorra, y el ROI simplemente no está ahí para justificar el costo de crear un modelo de dominio enriquecido. ([Fowler] habla de esto con cierta profundidad). Esto elimina el problema bastante bien, porque si no hay objetos, no hay desajuste de impedancia.
2. Aceptación incondicional.
Los desarrolladores simplemente abandonan por completo el almacenamiento relacional y usan un modelo de almacenamiento que se adapta a la forma en que sus idiomas de elección miran al mundo. Los sistemas de almacenamiento de objetos, como el proyecto db4o, resuelven el problema ordenadamente almacenando objetos directamente en el disco, eliminando muchos (pero no todos) los problemas mencionados anteriormente; no existe un "segundo esquema", por ejemplo, porque el único esquema utilizado es el de las definiciones de objeto en sí. Mientras que muchos DBA se desvanecerán ante la idea, en un mundo cada vez más orientado al servicio, que evita la idea del acceso directo a los datos pero que requiere que todos los accesos pasen por la puerta de enlace del servicio, encapsulando el mecanismo de almacenamiento lejos de miradas indiscretas. Es factible imaginar que los desarrolladores almacenan datos en una forma que es mucho más fácil para ellos usar, en lugar de DBA.
3. Mapeo manual.
Los desarrolladores simplemente aceptan que después de todo no es un problema tan difícil resolverlo manualmente, y escriben un código de acceso relacional directo para devolver las relaciones al lenguaje, acceder a las tuplas y llenar los objetos según sea necesario. En muchos casos, este código podría incluso ser generado automáticamente por una herramienta que examina los metadatos de la base de datos, eliminando algunas de las principales críticas de este enfoque (es decir, "es demasiado código para escribir y mantener").
4. Aceptación de las limitaciones de O / RM.
Los desarrolladores simplemente aceptan que no hay manera de cerrar de manera eficiente y fácil el desajuste de O / R, y usan un O / RM para resolver el problema del 80% (o 50% o 95%, o el porcentaje que parezca apropiado) y hacer uso de SQL y el acceso basado en las relaciones (como JDBC "raw" o ADO.NET) para llevarlos más allá de aquellas áreas donde un O / RM podría crear problemas. Sin embargo, hacerlo conlleva una parte justa de los riesgos, ya que los desarrolladores que usan un O / RM deben conocer cualquier almacenamiento en caché que la solución O / RM hace dentro de él, porque el acceso relacional "en bruto" claramente no podrá aprovechar. esa capa de almacenamiento en caché
5. Integración de conceptos relacionales en los idiomas.
Los desarrolladores simplemente aceptan que este es un problema que debe ser resuelto por el lenguaje, no por una biblioteca o marco. Durante la última década o más, el énfasis en soluciones al problema O / R se ha centrado en tratar de acercar objetos a la base de datos, de modo que los desarrolladores puedan enfocarse exclusivamente en la programación en un paradigma único (ese paradigma es, por supuesto, un objeto ) Sin embargo, en los últimos años, el interés por los lenguajes de "secuencias de comandos" con un conjunto y soporte de listas mucho más sólido, como Ruby, ha suscitado la idea de que tal vez otra solución sea apropiada: traiga conceptos relacionales (que, en esencia, se basan en conjuntos) en los principales lenguajes de programación, lo que facilita cerrar la brecha entre "conjuntos" y "objetos". Hasta ahora, el trabajo en este espacio ha sido limitado, restringido principalmente a proyectos de investigación y / o lenguajes "marginales", pero varios esfuerzos interesantes están ganando visibilidad dentro de la comunidad, como lenguajes híbridos funcionales / de objeto como Scala o F #, así como integración en lenguajes OO tradicionales, como el proyecto LINQ de Microsoft para C # y Visual Basic . Uno de esos esfuerzos que fracasó, desafortunadamente, fue la estrategia SQL / J; incluso allí, el enfoque fue limitado, no buscando incorporar conjuntos a Java, sino simplemente permitir que las llamadas SQL integradas sean preprocesadas y traducidas al código JDBC por un traductor.
6. Integración de conceptos relacionales en marcos.
Los desarrolladores simplemente aceptan que este problema se puede resolver, pero solo con un cambio de perspectiva. En lugar de confiar en el lenguaje o en los diseñadores de la biblioteca para resolver este problema, los desarrolladores toman una visión diferente de los "objetos" que son de naturaleza más relacional, creando marcos de dominio que se construyen más directamente alrededor de construcciones relacionales. Por ejemplo, en lugar de crear una clase Person que contenga sus datos de instancia directamente en campos dentro del objeto, los desarrolladores crean una clase Person que contiene sus datos de instancia en una instancia RowSet (Java) o DataSet (C #), que se puede ensamblar con otros RowSets / DataSets en un bloque de datos fácil de enviar para actualizar contra la base de datos, o desempaquetado desde la base de datos en los objetos individuales.

¿Es LINQ una especie de asignador relacional de objetos?

LINQ en sí mismo es un conjunto de extensiones de lenguaje para ayudar a consultar, leer y reducir el código. LINQ to SQL es un tipo de OR Mapper, pero no es particularmente poderoso. El marco de la entidad a menudo se denomina OR Mapper, pero hace mucho más .

Existen muchas otras implementaciones LINQ to X , incluyendo LINQ a NHibernate y LINQ a LLBLGenPro que ofrecen OR Mapping y marcos de apoyo de una manera similar a Entity Framework.

Si solo estás aprendiendo LINQ, te recomendaría que te apegues a LINQ to Objects para tener una idea, en lugar de sumergirte en uno de los sabores más complicados :-)

LINQ en sí no es un ORM. LINQ es las características y los métodos del idioma que existen al permitirle consultar objetos como SQL.

"LINQ to SQL" es un proveedor que nos permite usar LINQ contra objetos SQL fuertemente tipados.

LINQ no es un ORM en absoluto. LINQ es una forma de consultar "cosas", y puede verse más o menos como una extensión de lenguaje similar a SQL para diferentes cosas (IEnumerables).

Hay varios tipos de "cosas" que se pueden consultar, entre ellas las bases de datos de SQL Server. Esto se llama LINQ-to-SQL. La forma en que funciona es que genera clases (implícitas) basadas en la estructura de la base de datos y su consulta. En este sentido, funciona mucho más como un generador de código.

LINQ-to-SQL no es un ORM porque no intenta en absoluto resolver el desajuste de la impedancia relacional del objeto. En un ORM usted diseña las clases y luego las mapea manualmente en tablas o deja que el ORM genere la base de datos. Si luego cambia la base de datos por cualquier razón (por lo general, refactorización, renormalización, desnormalización), muchas veces puede mantener las clases tal como están cambiando la asignación.

LINQ-to-SQL no hace nada por el estilo. Sus consultas LINQ se acoplarán estrechamente a la estructura de la base de datos. Si cambia la base de datos, probablemente también deba cambiar el LINQ.

LINQ to SQL (parte de Visual Studio 2008) es un OR Mapper.

LINQ es un nuevo lenguaje de consulta que se puede utilizar para consultar muchos tipos diferentes de fuentes.

Linq To SQL usando el diseñador dbml sí, de lo contrario Linq es solo un conjunto de métodos de extensión para Enumerables.