Entity Framework 4 vs NHibernate [cerrado]


114

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.


31
Me gustaría una actualización de esta comparación. ¿Ha pasado mucho desde el '09?
Phil

Respuestas:


66

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.


13
+1 Tienes razón. NH es solo maduro. EF se pondrá al día a finales de año. La versión 4.0 ya ha hecho una entrada espectacular. Dale un poco de tiempo y será a prueba de balas a mediados de 2011.

15
-1 Para "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". Existe ISession.Merge en NHibernate, que es mucho mejor que las entidades de seguimiento automático para el desarrollo de N-Tier por muchas razones.
Alex Burtsev

12
@Alex - ¿De qué manera NHibernate es una solución "lista para usar"? Solo para aclarar; "Fuera de la caja" significa que funciona con una instalación básica de Visual Studio. Eso es un -1 injustificado allí mismo.
Doctor Jones

9
@DoctaJonez - De la forma en que lo leí, Alex estaba impugnando la idea de que NH no tiene nada comparable a las entidades de seguimiento automático, ni la parte de que está "fuera de la caja".
Jerph

2
De hecho, he descubierto que EF4 tiene un mapeo de herencia más flexible. Por ejemplo, puede usar 2 tablas (TPT) como clase base + clase de nivel 1 y agregar discriminador a la tabla de nivel 1, lo que permite dividir a clases de nivel 2. En NH, el discriminador solo se puede definir en la clase base.
Danny Varod

37

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.


1
EF se ha lanzado bajo la licencia Apache 2, que debería ayudar con la extensibilidad.
CMircea

@MirceaChirea Eso es, una gran noticia, no esperaba esto, navegando por el código fuente de EF en este momento, lectura bastante interesante.
Alex Burtsev

2
-1 por hacer varias declaraciones precedidas de "No he usado esto, pero estoy hablando de todos modos".
Kyeotic

@Tyrsius Mi respuesta fue escrita, hace casi 3 años, no he estado usando EF durante mucho tiempo, algunas cosas podrían mejorar, puede editar mi respuesta para actualizar al estado actual de EF.
Alex Burtsev

2
Admite que nunca ha utilizado entidades de seguimiento automático, pero las descarta. ¿Qué tal si solo habla de lo que sabe y omite las conjeturas ignorantes, especialmente porque todo el párrafo está bastante mal?
Tom Halladay

25

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.


13
¿Ha probado ActiveWriter? Entity Framework está absolutamente dirigido al espacio empresarial. No estoy de acuerdo con la mayor parte de lo que dijiste.
Michael Maddox

1
No esté de acuerdo todo lo que quiera, pero el hecho de que NHibernate ha existido por más tiempo es algo que las empresas NO pasan por alto.
zowens

21
-1 Esta no es una buena comparación entre NHibernate y Entity Framework. Comparar los dos agrupando EF con LINQ to SQL solo b / c tiene arrastrar y soltar es falso en el mejor de los casos. En cuanto a la complejidad, ¿qué es exactamente lo que NHibernate puede hacer que EF 4 no puede?
Kevin Babcock

14
Almacenamiento en caché de segundo nivel, sus consultas están ALTAMENTE optimizadas, NH lo obliga a usar el patrón UnitOfWork, además las asignaciones no se atascan en un solo archivo. Mi opinión (basada en la experiencia) es que NHibernate es más eficiente. No estoy de acuerdo conmigo en eso, pero dije que esa era mi opinión. Mi punto en mi respuesta TODAVÍA es válido, AMBOS tienen sus fortalezas y debilidades. Nadie puede negar eso.
zowens

2
@ MakerOfThings7 eso es patético ... toda esta pregunta es subjetiva. Despierta ...
zowens

23

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


De hecho, en mono-project.com/Compatibility se lee "EntityFrameworks - No disponible", y parece que nadie está interesado en implementarlo. Entonces, al menos durante unos años, es NHibernate o nada.
user276648

12

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.


10

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.


7
No olvide el soporte de LINQ. NHibernate todavía no es bueno en eso.
Arnis Lapsa

1
@Arnis, ¿puede proporcionar algún enlace para respaldar esa opinión?
Michael Maddox

2
@Michael, esto es evidente cuando miras las publicaciones del blog de Ayande sobre el tema. LINQ to NH se basa en los criterios API en la actualidad. La API de criterios no permite algunas de las funciones de consulta más complejas que puede hacer HQL. La próxima versión de LINQ to NH utilizará HQL en lugar de criterios API.
zowens

5

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

NHibernate vs Entity Framework


¿Cuál es el punto de tu respuesta? yourlogicalfallacyis.com/bandwagon
Răzvan Flavius ​​Panda

Que de acuerdo con la tendencia, la gente está comenzando a usar EntityFramework en Google más con el tiempo. Y pueden tener una buena razón para ello. Quizás empezó a ser mejor.
Tomas Kubes

Ese podría ser el caso, también podría ser el caso de que sea lo que se sugiere por defecto para ser utilizado por MS. Además, las herramientas para EF son bastante buenas.
Răzvan Flavius ​​Panda

4

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.


3

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.


1

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.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.