entity framework - Manual DAL y BLL vs. ORM

entity-framework devexpress (8)

Como otros explican, hay una dificultad fundamental con los ORM que hacen que ninguna solución existente haga un muy buen trabajo al hacer lo correcto, la mayoría de las veces. Este artículo en el blog: The Vietnam Of Computer Science se hace eco de algunos de mis sentimientos al respecto.

El resumen ejecutivo es algo similar a las suposiciones y optimizaciones que son incompatibles entre el objeto y los modelos relacionales. aunque los retornos iniciales son buenos, a medida que avanza el proyecto, las abstracciones del ORM se quedan cortas, y la sobrecarga adicional de trabajar a su alrededor tiende a cancelar los éxitos.

¿Qué enfoque es mejor: 1) usar un sistema ORM de terceros o 2) escribir manualmente código DAL y BLL para trabajar con la base de datos?

1) En uno de nuestros proyectos, decidimos usar el sistema DevExpress XPO ORM, y nos topamos con muchos problemas leves que desperdiciaban gran parte de nuestro tiempo. Y de vez en cuando encontramos problemas y excepciones que provienen de este ORM, y no tenemos una comprensión y control total de esta "caja negra".

2) En otro proyecto, decidimos escribir el DAL y BLL desde cero. Aunque esto implicaba escribir código aburrido muchas, muchas veces, pero este enfoque resultó ser más versátil y flexible: teníamos control total sobre la forma en que se guardaban los datos en la base de datos, cómo se obtenía de ella, etc. Y todos los errores podían ser arreglado de una manera directa y fácil.

¿Qué enfoque es generalmente mejor ? Tal vez el problema es solo con el ORM que utilizamos (DevExpress XPO), y tal vez otros ORM son mejores (como NHibernate)?

¿Vale la pena usar ADO Entiry Framework ?

Descubrí que DotNetNuke CMS usa su propio código DAL y BLL. ¿Qué hay de otros proyectos?

Me gustaría obtener información sobre tu experiencia personal : ¿qué enfoque utilizas en tus proyectos, que es preferible?

Gracias.

He usado Bold para Delphi cuatro años. Es genial, pero ya no está disponible para la venta y carece de algunas características, como la vinculación de datos. ECO, el sucesor tiene todo eso. No, no estoy vendiendo licencias ECO o algo por el estilo, pero creo que es una pena que tan poca gente se dé cuenta de lo que MDD (Model Driven Development) puede hacer. Capacidad para resolver problemas más complejos en menos tiempo y menos errores. Esto es muy difícil de medir, pero he escuchado algo así como 5-10 de desarrollo más eficiente. Y a medida que trabajo con él todos los días, sé que esto es verdad.

Tal vez un desarrollador tradicional que se centra en datos y SQL dice:

"¿Pero qué hay del rendimiento?"
"¡Puedo perder el control de lo que SQL se ejecuta!"

Bien...

Si desea cargar 10000 instancias de una tabla lo más rápido posible, puede ser mejor utilizar los procedimientos almacenados, pero la mayoría de las aplicaciones no lo hacen. Tanto Bold como ECO usan consultas SQL simples para cargar datos. El rendimiento depende en gran medida del número de consultas a la base de datos para cargar una cierta cantidad de datos. El desarrollador puede ayudar diciendo que estos datos pertenecen el uno al otro. Cargúelos tan effiecent como sea posible.
Las consultas reales que se ejecutan pueden, por supuesto, registrarse para detectar cualquier problema de rendimiento. Y si realmente desea utilizar su consulta SQL hiper optimizada, esto no es un problema, siempre que no actualice la base de datos.

Hay muchos sistemas ORM para elegir, especialmente si usa dot.net. Pero, sinceramente, es muy difícil hacer un buen marco ORM. Debe estar concentrado alrededor del modelo. Si el modelo cambia, debería ser una tarea fácil cambiar la base de datos y el código que depende del modelo. Esto hace que sea fácil de mantener. El costo de hacer cambios pequeños pero muchos es muy bajo. Muchos desarrolladores cometen el error de centrarse en la base de datos y adaptar todo al respecto. En mi opinión, esta no es la mejor manera de trabajar.

Más debería probar ECO. Es gratis usar un tiempo ilimitado siempre que el modelo no tenga más de 12 clases. ¡Puedes hacer mucho con 12 clases!

Le sugiero que use Code Smith Tool para crear Nettiers, que es una buena opción para el desarrollador.

Mi experiencia personal ha sido que ORM es generalmente una completa pérdida de tiempo.

Primero, considere la historia detrás de esto. En los años 60 y principios de los 70, teníamos estos DBMS usando los modelos jerárquicos y de red. Estos fueron un poco difíciles de usar, ya que al consultarlos, tuvo que lidiar con todos los mecanismos de recuperación: seguir los enlaces entre los registros de todo el lugar y lidiar con la situación cuando los enlaces no eran los enlaces que quería ( por ejemplo, estaban apuntando en la dirección incorrecta para su consulta particular). Así que Codd ideó la idea de un DBMS relacional: especifica las relaciones entre las cosas, por ejemplo, en tu consulta solo lo que deseas, y deja que el DBMS trate de descifrar la mecánica de recuperarlo. Una vez que tuvimos un par de buenas implementaciones de esto, los chicos de la base de datos se llenaron de alegría, todos cambiaron a eso, y el mundo estaba feliz.

Hasta que los chicos de OO llegaron al mundo de los negocios.

Los chicos de OO encontraron este desajuste de impedancia: los DBMS utilizados en la programación de negocios eran relacionales, pero internamente los chicos de OO almacenaban cosas con enlaces (referencias), y encontraban cosas averiguando los detalles de qué enlaces tenían que seguir y seguirlos. Sip: este es esencialmente el modelo DBMS jerárquico o de red. Por lo tanto, pusieron mucho esfuerzo (a menudo ingenioso) para volver a acoplar ese modelo jerárquico / de red a las bases de datos relacionales, eliminando por accidente muchas de las ventajas que nos brinda RDBMS.

Mi consejo es aprender el modelo relacional, diseñar su sistema a su alrededor si es adecuado (es muy frecuente) y usar la potencia de su RDBMS. Evitará la falta de coincidencia de impedancia, generalmente encontrará que las consultas son fáciles de escribir y evitará problemas de rendimiento (como que su capa ORM tome cientos de consultas para hacer lo que debería hacer en una).

Hay una cierta cantidad de "mapeo" que se debe hacer cuando se trata de procesar los resultados de una consulta, pero esto es bastante fácil si se piensa de la manera correcta: el encabezado de la relación de resultados se correlaciona con una clase, y cada tupla en la relación es un objeto. Dependiendo de la lógica adicional que necesite, puede o no valer la pena definir una clase real para esto; puede ser bastante fácil simplemente trabajar a través de una lista de hashes generados a partir del resultado. Simplemente revise y procese la lista, haga lo que debe hacer y listo.

Puede intentar usar NHibernate. Como es de código abierto, no es exactamente una caja negra. Es muy versátil y tiene muchos puntos de extensibilidad para que pueda conectar su propia funcionalidad adicional o de reemplazo.

Comentario 1:

NHibernate es un verdadero ORM, ya que le permite crear una asignación entre su modelo de dominio arbitrario (clases) y su modelo de datos arbitrario (tablas, vistas, funciones y procedimientos). Usted le dice cómo desea que sus clases se mapeen en las tablas, por ejemplo, si esta clase asigna a dos tablas unidas o dos clases asignan a la misma tabla, si esta propiedad de clase se correlaciona con una relación de muchos a muchos, etc. NHibernate espera que su modelo de datos esté en su mayoría normalizado, pero no requiere que su modelo de datos se corresponda exactamente con su modelo de dominio, ni genera su modelo de datos.

Comentario 2:

El enfoque de NHibernate es permitirle escribir cualquier clase que le guste, y luego decirle a NHibernate cómo asignar esas clases a las tablas. No existe una clase base especial de la cual heredar, ninguna clase de lista especial en la que deban estar todas sus propiedades de uno a muchos, etc. NHibernate puede hacer su magia sin ellas. De hecho, se supone que las clases de objeto de negocio no tienen ninguna dependencia de NHibernate en absoluto. Las clases de objeto de negocio, por sí mismas, no tienen absolutamente ninguna persistencia o código de base de datos en ellas.

Lo más probable es que descubra que puede ejercer un control muy detallado sobre las estrategias de acceso a los datos que utiliza NHibernate, hasta el punto de que NHibernate también sea una excelente opción para sus casos complejos. Sin embargo, en cualquier contexto dado, puedes usar NHibernate o no usarlo (a favor de un código DAL más personalizado), como desees, porque NHibernate intenta no estorbarte cuando no lo necesitas. Entonces puede usar un DAL personalizado o DevExpress XPO en una clase BLL (o método), y puede usar NHibernate en otro.

Recientemente participé en un proyecto interesante lo suficientemente grande. No me uní desde el principio y tuvimos que apoyar la arquitectura ya implementada. El acceso a los datos a todos los objetos se implementó mediante procedimientos almacenados y métodos wrapper generados automáticamente en .NET que devolvieron objetos DataTable. El proceso de desarrollo en dicho sistema fue muy lento e ineficiente. Tuvimos que escribir un gran procedimiento almacenado en PL / SQL para cada consulta, que se podía expresar en una consulta LINQ simple. Si hubiéramos usado ORM, habríamos implementado el proyecto varias veces más rápido. Y no veo ninguna ventaja de tal arquitectura.

Lo admito, es solo un proyecto particular no muy exitoso, pero hice una conclusión: antes de negarse a usar ORM, piensen dos veces, ¿realmente necesitan tanta flexibilidad y control sobre la base de datos? Creo que en la mayoría de los casos no vale la pena perder tiempo y dinero.

Recientemente tomé la decisión de usar Linq para SQL en un nuevo proyecto, y realmente me gusta. Es liviano, de alto rendimiento, intuitivo y tiene muchos gurús en Microsoft (y otros) que bloguean al respecto.

Linq to SQL funciona al crear una capa de datos de objetos c # desde su base de datos. DevExpress XPO funciona en la dirección opuesta, creando tablas para sus objetos comerciales C #. Se supone que el Entity Framework funciona de cualquier manera. Soy un tipo de base de datos, por lo que la idea de un marco de diseño de la base de datos para mí no tiene mucho sentido, aunque puedo ver el atractivo de eso.

Mi proyecto Linq to SQL es un proyecto de tamaño mediano (cientos, tal vez miles de usuarios). Para proyectos más pequeños, a veces solo uso los objetos SQLCommand y SQLConnection, y hablo directamente con la base de datos, con buenos resultados. También utilicé objetos SQLDataSource como contenedores para mi CRUD , pero estos parecen torpes.

Los DAL tienen más sentido cuanto más grande sea su proyecto. Si es una aplicación web, siempre uso algún tipo de DAL porque tienen protecciones incorporadas contra cosas como ataques de inyección SQL, mejor manejo de valores nulos, etc.

Debatí si utilizar Entity Framework para mi proyecto, ya que Microsoft dice que esta será su solución de acceso para el acceso a datos en el futuro. Pero EF se siente inmadura para mí, y si busca para Entity Framework, encontrará varias personas que están luchando con problemas pequeños y obtusos. Sospecho que la versión 2 será mucho mejor.

No sé nada sobre nHibernate, pero hay personas que lo aman y no usarían nada más.

Tal vez un poco de ambos es lo correcto. Puede usar un producto como SubSonic. De esta forma, puede diseñar su base de datos, generar su código DAL (eliminando todas las cosas aburridas), usar clases parciales para ampliarlo con su propio código, usar procedimientos almacenados si lo desea, y generalmente hacer más cosas.

Eso es lo que hago. Encuentro que es el equilibrio correcto entre automatización y control.

También me gustaría señalar que creo que estás en el camino correcto al probar diferentes enfoques y ver qué funciona mejor para ti . Creo que esa es la fuente de tu respuesta.