Entity Framework 4 vs NHibernate [cerrado]

Mucho se ha hablado de la primera versión de Entity Framework en la web (también en stackoverflow) y está claro que no fue una buena elección cuando ya tenemos una alternativa mejor como NHibernate. Pero no puedo encontrar una buena comparación entre Entity Framework 4 y NHibernate. Podemos decir que hoy NHibernate es el líder entre todos los ORM .NET, pero podemos esperar que Entity Framework 4 desplace a NHibernate de esta posición. Creo que si Microsoft realmente ha inyectado muy buenas características en EF4, puede ofrecer una buena competencia a NHibernate, ya que tiene integración con Visual Studio, es más fácil trabajar con él y siempre se da preferencia a los productos MS en la mayoría de las tiendas.

EF4 tiene una respuesta lista para usar con respecto al desarrollo de n niveles, en "entidades de seguimiento automático". Nadie ha publicado un código comparable para NHib.

NHib tiene muchas características que no se han mencionado como parte de EF4. Estos incluyen la integración de caché de segundo nivel. También tiene una mayor flexibilidad en el mapeo de herencia, una mejor integración con procesos almacenados / funciones de base de datos / SQL / disparadores personalizados, soporte para propiedades de fórmulas, etc. En mi opinión, es básicamente más maduro como ORM.

Actualización: no he usado Entity Framework desde la versión 4.0, por lo que mi respuesta puede estar desactualizada. Todavía estoy usando NH o ADO .NET puro en mis proyectos. Y ni siquiera quiero ver las novedades de EF desde 4.0, porque NH funciona perfectamente.

En realidad, es bastante fácil compararlos cuando has usado ambos. Existen algunas limitaciones serias con EF4, puedo nombrar algunas que encontré por mí mismo:

Problemas de EF4:

• Carga ansiosa y modelando el resultado : el sistema de carga ansiosa EF4 (Incluir ("Ruta")) genera SQL incorrecto, con JOIN en bucle, que ejecutarán miles (no literalmente) más lento para relaciones de muchos a muchos que SQL escrito a mano (es efectivamente inutilizable).
• Materializer no puede materializar entidades asociadas : si cree que puede superar el problema anterior proporcionando su propia consulta SQL, está equivocado. EF4 no puede materializar (mapear) entidades asociadas de la consulta JOIN SQL, solo puede cargar datos de una tabla (por lo tanto, si tiene Order.Product, SELECT * FROM order LEFT JOIN Product se inicializará solo el objeto Order, Product permanecerá nulo, pensó que todos los datos necesarios se obtienen en la consulta para iniciarlo). Esto se puede superar utilizando el complemento de la comunidad EFExtensions, pero el código que tendrá que escribir para esto es realmente feo (lo intenté).

• Entidades de seguimiento automático: Muchos dicen que las entidades de seguimiento automático son geniales para el desarrollo de N niveles, incluida la respuesta principal en este hilo. Aunque ni siquiera los he probado, puedo decir que no. Todas las entradas pueden falsificarse, no puedes simplemente tomar los cambios que te envía el usuario y aplicarlos a la base de datos, ¿por qué no darle al usuario datos directos? acceso a la base entonces? De cualquier forma, tendrá que cargar los datos que el usuario está a punto de cambiar de la base de datos, verifique que exista | no exista, verifique los permisos, etc. tiene que cargar esta entidad desde la base de datos y determinar su estado y otras cosas, por lo que esta información es inútil, al igual que las entidades de seguimiento automático a menos que tenga un sistema privado de confianza de n niveles para uso interno, en cuyo caso tal vez podría dar simplemente Acceso a la base de datos.

• Registro, eventos, integración de la lógica empresarial: EF4 es como una caja negra, hace algo y no tienes idea de lo que hace. Solo hay un evento OnSavingChanges en el que puede poner cierta lógica de negocios que necesita ejecutar antes de que suceda algo con DB, y si necesita aplicar algunos cambios a los objetos de negocios antes de que suceda algo, tendrá que buscar en ObjectStateManager, y esto es realmente feo. , el código puede volverse enorme. Si, por ejemplo, utiliza el patrón Repository y qué se le notificará sobre los cambios realizados en la base de datos en forma de objeto limpio, tendrá dificultades para hacerlo con EF.

• Extensibilidad: Todo el código EF es privado e interno, si no le gusta algo (y no le gustará MUCHO si se toma en serio el uso de EF), de ninguna manera cambiará esto de manera fácil, de hecho, estoy seguro es más fácil escribir tu propio ORM desde cero (lo hice) y luego hacer que EF funcione como necesites. Como ejemplo, eche un vistazo a la fuente de EFExtensions, se basa en métodos de extensiones y diferentes "trucos" para hacer que EF sea un poco más utilizable, y el código es bastante feo (y no es culpa de los autores, cuando todo en EF es privado, este es el único forma de extenderlo).

Puedo seguir escribiendo cosas malas sobre EF y lo doloroso que fue para mí trabajar con él durante 20 páginas, y tal vez lo haga.

¿Qué pasa con NHibernate? Es un nivel absolutamente diferente, es como comparar PHP con C #, EF4 es como en la edad de piedra, es como si EF estuviera 10 años por detrás de NHibernate en el progreso del desarrollo, y de hecho lo es, Hibernate se inició en 2001. Si tienes tiempo libre para aprender y activar Nhibernate, hazlo.

Aquí está la cosa. NHibernate y Entity Framework son realmente para dos audiencias diferentes, en mi opinión. NHibernate sería mi elección para construir un sistema con asignaciones complejas, fórmulas y restricciones (básicamente cualquier empresa). Si quisiera comenzar a ejecutarlo con un acceso simple a los datos, usaría Entity Framework o LINQ-to-SQL. NHibernate no tiene una experiencia clara de "arrastrar y soltar" como EF. Ambos tienen sus puntos fuertes y sus inconvenientes. La comparación de manzanas con manzanas, francamente, no te lleva a ninguna parte.

Si cree que alguna vez querrá ejecutar su código en Mono, NHibernate es probablemente una mejor opción sin importar lo que digan las listas de verificación de funciones ...

Editar, 13/8/2012:

Entity Framework ha sido de código abierto y ahora se incluye en Mono a partir de 2.11.3. Esta respuesta ahora está desactualizada y no se debe confiar en ella.

http://weblogs.asp.net/scottgu/archive/2012/07/19/entity-framework-and-open-source.aspx

Mi opinión sobre esto es que EF4.0 ha recorrido un largo camino desde la versión 1.0 y se está poniendo al día con Nhibernate en funcionalidad, pero aún no ha terminado.

Sin embargo, es Microsoft, listo para usar, y hace el 100% de lo que el 95% de las aplicaciones necesitan que haga. Sin embargo, NHibernate ha estado haciendo lo mismo durante años. La versión 5.0 o 6.0 puede ponerse al día o incluso superar a NHibernate.

Este es mi consejo: si tienes tiempo para aprender ambos, hazlo. Hay varias razones para elegir una u otra. Si está escribiendo código para una corporación, es realista esperar empleados capaces que estén familiarizados con EF, ya que está en todos los libros y lo que los niños aprenden en la universidad. Si EF cumple con sus requisitos (piense en esto mucho antes de decir que sí), entonces es una solución perfectamente buena por ahora, y en unos años puede (ok, lo más probable es que) supere a NHibernate.

NHibernate es un producto muy maduro con algunos años en EF y lo más probable es que haga todo lo que quisiera hacer y algo más. Ha sido el mejor ORM desde hace un tiempo y mucha gente lo usa.

Creo que el hecho de que EF 4 tenga la capacidad de usar POCO y la carga diferida diferida será muy grande. Definitivamente pude verlo ganando terreno con el nuevo lanzamiento.

Existe una tendencia obvia de aumentar la popularidad de EF sobre NHibernate, vea la imagen.

Mis 2 centavos: usamos ef en nuestro cliente de escritorio para algunos cahing, etc., sin cargas hi. Un NHib en el lado del servidor: utiliza sesiones sin estado, generación de ID de hilo y lotes. Es bastante rápido para insertar más de 3000 mensajes en db por segundo. Además, es muy flexible y soporta muchas bases de datos, lo cual es crucial para nuestro producto.

Mapear directamente a los procedimientos almacenados con una combinación de Linq para una capa lógica parece el enfoque más sencillo. Sin xml. Genere sql solo para consultas interesantes que se usan con menos frecuencia o no son adecuadas para procedimientos almacenados.

Los objetos se cargan y almacenan a través de SP estándar. Este enfoque permite el uso de dos inicios de sesión SQL. Uno para el acceso de clase a través de SP (permisos de solo ejecución) y otro para un módulo de linq lógico que permite el acceso directo a la tabla.

Elegir entre ORM por popularidad no es lo mejor que se puede hacer. He intentado mudarme a EF los últimos 2 años y todo lo que puedo decir es, ¿por qué demonios todavía lo intento?

ATM mi punto de vista sobre EF es: "Está hecho para sistemas de bits realmente pequeños con no más de 3 tablas con menos de 1 relación (0 es mejor)".

¿Y por qué pienso así? 1. Intente actualizar un gráfico desconectado y vea su modelo rayado;

1. Intente hacer TPH con árboles heredados profundos y verá que está asignado a una sola jerarquía o el sistema se romperá.

2. Intente realizar consultas más engorrosas y observe cómo todo el sistema se come la pila: D ... los desbordamientos ocurren con mucha frecuencia.

3. Los tipos de datos XML de mapas se basan en extensiones o en las propiedades NotMapped más "odiadas" ... y es aún peor.

4. Intente mezclar consultas SQL en Linq para consultas más finas y romperá la pared jajaja.

5. Y lo último y más importante, EF no admite la fórmula de propiedad ('recursos increíbles que tiene NH para bases de datos heredadas'), y no admite asignaciones de tipos complejos para la misma tabla y tablas relacionadas.

Ese es mi 10cc.