Entity Framework 4 vs NHibernate [cerrado]

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 pure ADO. NET en mis proyectos. Y ni siquiera quiero ver qué hay de nuevo en EF desde 4.0, porque NH funciona perfectamente.

En realidad es bastante fácil compararlos cuando se han utilizado ambos. Hay algunas limitaciones serias con EF4, puedo nombrar algunas que encontré por mi mismo:

Problemas EF4:

• Ansiosa Carga y conformación de la resultado: EF4 eager loading system (Include("Path")) genera SQL incorrecto, con JOIN de bucle , que ejecutará miles(no literalmente) de tiempo más lento para muchas relaciones que SQL escrito a mano (es efectivamente inutilizable).
• Materializer no puede materializar entidades asociadas: Si puede pensar que puede superar el problema anterior proporcionándole su propia consulta SQL, está equivocado. EF4 no puede materializar (mapear) entidades asociadas desde JOIN SQL query, solo puede cargar los datos de una tabla (así que si usted tiene orden.Product, SELECT * FROM order LEFT JOIN Product will initialize only Order object, Product will remain null, thought all necessary data is fetched in query to init it). Esto se puede superar utilizando EFExtensions community add-on, pero el código que tendrá que escribir para esto es realmente feo (lo intenté).

• Entidades de auto-seguimiento: Muchos dicen que las entidades de auto-seguimiento son geniales para el desarrollo de N-tier, incluida la respuesta principal en este hilo. Pensé que ni siquiera darles una oportunidad, puedo decir que no lo son.Cada entrada se puede falsificar, no puede simplemente tomar los cambios que el usuario le envía y aplicarlos a la base de datos, ¿por qué no dar al usuario acceso directo a la base de datos entonces? De cualquier manera usted tendrá que cargar el usuario de datos está a punto de cambiar de la base de datos, comprobar que existe / no existe hacer comprobaciones de permisos etc etc. No puede confiar en el usuario en el estado de la entidad que está enviando al servidor, de todos modos tendrá que cargar esta entidad desde la base de datos y determinar es el estado y otras cosas, por lo que esta información es inútil, al igual que las entidades de auto-Seguimiento a menos que haga un sistema privado de confianza n-tier para uso interno, en cuyo caso tal vez podría dar acceso simple a la base de datos. (Esos son mis pensamientos sobre las Entidades ST y N-tire, no estoy muy expericned en N-Tier, por lo que puede cambiar, si malinterpreté algo aquí comentarlo)

• Registro, eventos, integración de lógica de negocios: EF4 es como black box, hace algo y no tienes idea lo que hace. Solo hay un evento en SavingChanges donde puedes poner algo de lógica de negocios que necesitas ejecutar antes de que algo suceda con DB, y si necesitas aplicar algunos cambios a objetos de negocios antes de que algo suceda tendrás que cavar en ObjectStateManager, y esto es realmente feo, el código puede volverse enorme. Si, por ejemplo, utiliza el patrón de repositorio y lo que debe ser notificado sobre los cambios realizados en la base de datos en forma de objeto limpio, tendrá dificultades para hacer esto con EF.

• Extensibilidad: Todo el código EF es privado e interno, si no te gusta algo (y no te gustará MUCHO si te tomas en serio el uso de EF), de ninguna manera cambiarás esto de manera fácil, De hecho estoy seguro de que es más fácil escribir tu propio OR desde cero (lo hice) y luego haz que EF funcione como necesites. Como ejemplo, eche un vistazo a EFExtensions source, se basa en métodos de extensiones y diferentes "hacks" para hacer EF poco más usable, y el código es bastante feo (y no es los autores fallan, cuando todo en EF es privado esta es la única manera de extenderlo).

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

¿Y NHibernate? Es absolutamente diferente nivel, es como comparar PHP con C#, EF4 es como en la edad de Piedra, es como EF está 10 años atrás entonces NHibernate en el progreso del desarrollo, y de hecho es, Hibernate se inició en 2001. Si tener tiempo libre para aprender y encender Nhibernate, hacerlo.

Aquí está la cosa. NHibernate y Entity Framework son realmente para dos audiencias diferentes, en mi mente. NHibernate sería mi elección en la construcción de un sistema con asignaciones complejas, fórmulas y restricciones (básicamente cualquier empresa). Si quisiera comenzar a correr con acceso a datos simple, 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. Comparándolos manzanas-a-manzanas, francamente, no te lleva a ninguna parte.

Si crees que alguna vez quieres ejecutar tu código en Mono, NHibernate es probablemente una mejor opción sin importar lo que digan las listas de verificación de características...

Editar, 8/13/2012:

Entity Framework ha sido de código abierto, y ahora está incluido en Mono a partir de 2.11.3. Esta respuesta está ahora obsoleta 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 1.0 y se está poniendo al día con Nhibernate en funcionalidad, pero aún no está todo ahí.

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

Aquí está mi consejo if si tienes tiempo para aprender ambos, entonces hazlo. Hay varias razones para elegir una sobre la otra. Si está escribiendo código para una corporación, es realista esperar ser 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 largo y duro antes de decir que sí), entonces es una solución perfectamente adecuada por ahora, y en unos pocos años puede (ok, lo más probable es) superar a NHibernate.

NHibernate es un producto muy maduro con algunos años en EF y lo más probable es que lo haga todo lo que quisieras hacer y algo más. Ha sido el mejor OR 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 tracción con el nuevo lanzamiento.

Hay 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-utilizando sesiones sin estado, generación de id de hilo y lotes. Es bastante rápido en la inserción de mensajes 3k+en db por segundo. También es muy flexible y soporta gran cantidad de dbs, lo cual es crucial para nuestro producto.

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

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

Elegir entre OR por popularidad no es lo mejor. He tratado de pasar a EF los últimos 2 años y todo lo que puedo decir es, ¿por qué demonios todavía intento?

ATM mi punto de vista sobre EF es: "Está hecho para sistemas de bits muy 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 el scratch de su modelo;

1. Trate de hacer TPH con heredado profundo árboles y usted encontrará que usted está schackled a una sola jerarquía o el sistema se romperá.

2. Trate de hacer consultas más engorrosas y ver todo el sistema comer fuera de la pila: D... los desbordamientos ocurren muy a menudo.

3. Map XML datatypes se basa en extensiones o en las propiedades NotMapped más "odiadas"... y es aún peor.

4. Intente mezclar la consulta SQL en Linq para obtener más consultas de finner y romperá el muro lol.

5. Y el por último y lo más importante, EF no admite la fórmula de propiedades ('un recurso impresionante que NH tiene para bases de datos heredadas'), y no admite asignaciones de tipos complejos para la misma tabla y tablas relacionadas.

Ese es mi 10cc.