O/R Mappers - Bueno o malo

Question

Realmente estoy desgarrado ahora entre el uso de trazadores O/R o simplemente apegándome al acceso a datos tradicional. Por alguna razón, cada vez que traigo mapeadores O/R, los desarrolladores compañeros se avergüenzan y hablan sobre los problemas de rendimiento o sobre cómo son malos en general. ¿Que me estoy perdiendo aqui? Estoy mirando LINQ to SQL y Microsoft Entity Framework. ¿Hay alguna base para alguna de estas afirmaciones? ¿Qué tipo de cosas debo comprometer si quiero usar un asignador O/R? Gracias.

Answer 1

El problema que veo con muchos de los correlacionadores O es que obtienes objetos de dominio inflados, que generalmente están muy asociados con el resto de tu marco de acceso a datos. Nuestros desarrolladores se avergüenzan de eso también :) Es más difícil trasladar estos objetos a otra tecnología de acceso a datos. Si usa L2S, puede echar un vistazo al código generado. Parece un completo desastre. NHibernate es probablemente uno de los mejores en esto. Sus entidades desconocen por completo su capa de acceso a los datos, si los diseña correctamente.

Answer 2

Entré por primera vez en el mapeo ORM y en las Capas de acceso a datos leyendo el libro de Rockford Lhotka, C# business objects. Pasó años trabajando en un marco para DAL. Si bien su marco original está bastante hinchado y, en algunos casos, excesivo, tiene algunas ideas excelentes. Recomiendo encarecidamente el libro para cualquiera que mire mapeadores ORM. Fui influenciado por su libro lo suficiente como para quitarle muchas de sus ideas y construirlas en mi propio marco y generación de código.

Answer 3

Esto parecerá una respuesta no relacionada al principio, pero: uno de mis intereses secundarios son los aviones de combate de la Segunda Guerra Mundial. Todas las naciones combatientes (EE. UU., Gran Bretaña, Alemania, URSS, Japón, etc.) construyeron un grupo de combatientes diferentes durante la guerra. Algunos de ellos usaban motores radiales (P47, Corsair, FW-190, Zero); algunos utilizan motores refrigerados por líquido en línea (Bf-109, Mustang, Yak-7, Spitfire); y algunos usaron dos motores en lugar de uno (P38, Do-335). Algunas usaban ametralladoras, algunas usaban cañones y otras usaban ambas. Algunos incluso fueron hechos de madera contrachapada, si te puedes imaginar.

Al final, todos fueron muy rápido, y en manos de un piloto competente y experimentado, dispararían a tu novato en un abrir y cerrar de ojos. No me imagino que muchos pilotos volaron pensando "oh, ese idiota está volando algo con un motor radial, no tengo que preocuparme por él en absoluto". Todos entendieron que había muchas maneras diferentes de lograr el objetivo final, y cada enfoque tenía sus ventajas y desventajas particulares, según las circunstancias.

El debate entre ORM y el acceso a datos tradicional es así, y le corresponde a cualquier programador ser competente con ambos enfoques, y elegir la opción adecuada para el trabajo en cuestión.

Answer 4

Luché con esta decisión durante mucho tiempo. Creo que dudaba por dos razones principales. En primer lugar, los correlacionadores O/R representaban una falta de control sobre lo que estaba sucediendo en una parte crítica de la aplicación y, en segundo lugar, porque muchas veces me han decepcionado las soluciones que son asombrosas para el caso del 90% pero miserables para el último 10%. Todo funciona para select * de autores, por supuesto, pero cuando aumenta la complejidad y tiene un sistema crítico de alto volumen y su carrera está en juego, siente que necesita tener el control completo para ajustar cada patrón de consulta y byte. por el cable. La mayoría de los desarrolladores, incluyéndome a mí, se frustran la primera vez que la herramienta nos falla, y no podemos hacer lo que tenemos que hacer, o nuestra necesidad se desvía del patrón establecido que admite la herramienta. Probablemente me llame la atención por mencionar defectos específicos en las herramientas, así que lo dejaré así.

Afortunadamente, Anderson Imes finalmente me convenció de probar CodeSmith con el netTiers template. (No, no trabajo para ellos.) Después de más de un año de usar esto, no puedo creer que no lo hayamos hecho antes. Mi equipo usa Visual Studio DB Pro, y en cada check-in nuestra construcción de integración continua elimina un nuevo conjunto de conjuntos de capa de acceso a datos.Esto maneja todas las cosas comunes de bajo riesgo automáticamente, sin embargo, aún podemos escribir sprocs personalizados para los bits difíciles y tenerlos incluidos como métodos en las clases generadas, y también podemos personalizar las plantillas para el código generado. Recomiendo mucho este enfoque. Puede haber otras herramientas que también permitan este nivel de control, y hay una plantilla más nueva de CodeSmith llamada PLINQO que usa LINQ to SQL bajo el capó. Todavía no hemos examinado (no lo hemos necesitado), pero este enfoque general tiene muchos méritos.

Jerry

Answer 5

No hay una respuesta simple a esto ya que cada proveedor de ORM tendrá sus propias ventajas y desventajas particulares. Algunas soluciones ORM son más flexibles que otras. La responsabilidad del desarrollador es comprenderlos antes de usar uno.

Sin embargo, tome LinqToSql - si está seguro de que no va a necesitar cambiarse de SQL Server, entonces esto resuelve muchos de los problemas comunes observados en los mapeadores ORM. Le permite agregar fácilmente procedimientos almacenados (como métodos estáticos), por lo que no solo se limita al SQL generado. Utiliza la ejecución diferida, por lo que puede encadenar consultas de manera eficiente. Utiliza clases parciales para permitirle agregar fácilmente la lógica personalizada a las clases generadas sin tener que preocuparse por lo que sucede cuando las vuelve a generar. Tampoco hay nada que te impida usar LINQ para crear tu propio DAL abstraído, sino que acelera el proceso. Lo principal, sin embargo, es que alivia el tedio y el tiempo necesarios para crear la capa CRUD básica.

Pero también hay inconvenientes. Habrá un estrecho acoplamiento entre las tablas y las clases, habrá una leve caída en el rendimiento, ocasionalmente puede generar consultas que no son tan eficientes como esperaba. Y está vinculado a SQL Server (aunque algunos otros technlogies ORM son agnósticos de base de datos).

Como dije, lo principal es conocer los pros y los contras antes de fijar sus colores a una metodología en particular.

Answer 6

Herramientas O/RM diseñadas para funcionar muy bien en la mayoría de las situaciones. Cacheará entidades para usted, ejecutará consultas en grandes cantidades, tiene un acceso optimizado de muy bajo nivel a los objetos que es mucho más rápido que la asignación manual de valores a las propiedades, le dan una manera muy fácil de incorporar variaciones de programación orientada a aspectos usando técnicas modernas como interceptores, administrará el estado de la entidad para usted y ayudará a resolver conflictos y muchos más.

Ahora bien, este enfoque generalmente se basa en la falta de comprensión de cómo funcionan las cosas a un nivel muy bajo. El problema más clásico es "SELECCIONE N + 1" (link).

He estado trabajando con NHibernate durante 2,5 años, y todavía estoy descubriendo algo nuevo sobre él casi a diario ...

Answer 7

buena. En la mayoría de los casos.

El beneficio de productividad del uso de un ORM, en la mayoría de los casos superará la pérdida de control sobre cómo se accede a los datos.

No hay muchos que eviten C#, para programar es MSIL o Assembly, aunque eso les daría más control.

Answer 8

Realmente depende de la situación.

Pasé de ser una empresa que usaba un ORM ajustado a una empresa que no usaba un ORM y escribía consultas SQL todo el tiempo.Cuando le pregunté acerca del uso de un ORM para simplificar el código, tengo esa mirada en blanco en la cara seguido por todos los aspectos negativos de la misma:

• su alto Inflar
• usted no tiene un control preciso sobre sus consultas y ejecutar las innecesarias
• hay un objeto pesado para mapeo de la tabla
• su código no se seca porque hay que repetir su auto

en una de

Bueno, después de trabajar allí durante un par de semanas, me había dado cuenta de que:

• tuvimos varias consultas que eran casi idénticos, y un montón de veces si había un error, sólo un puñado conseguiría fijo
• en lugar de almacenar en caché las consultas de tablas comunes, terminaríamos leyendo una tabla varias veces.
• Estábamos repitiendo nuestro yo por todo el lugar
• Teníamos varios niveles de nivel de habilidad, por lo que algunas consultas no se escribieron de la manera más eficiente.

Después de señalar la mayor parte de esto, escribieron un "DBO" porque no quería llamarlo ORM. Decidieron escribir uno desde cero en lugar de ajustar uno.

Además, muchos de los argumentos provienen de la ignorancia en contra de los sentimientos de ORM. Cada ORM que he visto permite realizar consultas personalizadas e, incluso, seguir las convenciones de ORM, puede escribir consultas muy complejas y detalladas, y normalmente son más fáciles de leer por los humanos. Además, tienden a ser muy SECOS, les das tu esquema y calculan el resto, hasta el mapeo de relaciones.

Los ORM modernos tienen muchas herramientas para ayudarlo, como las secuencias de comandos de migración, múltiples tipos de bases de datos a las que se accede a los mismos objetos para que pueda aprovechar las ventajas de los DB NOSQL y SQL. Pero debe elegir el ORM correcto para su proyecto si va a usar uno.