NHibernate vs. EF 4.1+

Question

Estoy tratando de decidir los pros y los contras de los 2 ORM principalmente en esta área.

1. compatibilidad con SQL Server 2008 R2 & 2012.
   • Esto es muy importante ya que simplemente no tenemos los recursos para depurar el escaso apoyo de la tecnología de pila de MS existente.
   • También está planificando el futuro, ya que 2012 está prácticamente listo y se planea migrar a él.
2. Soporte para .NET 4.0 y 4.5 (próxima)
   • Una vez más muy importante para casi la misma razón anterior.
3. Gestión de transacciones y consejos de tabla, por ejemplo. las fuerzas pueden forzar la búsqueda, leer sin procesar.
   • Muchas veces el optimizador de consultas hace bien su trabajo, otras veces deseo la flexibilidad para decirle qué hacer.
4. Apoyo para la conversación, el seguimiento de auto adjuntar & desprender
   • Esto es algo fundamental. Odio mantener la sesión abierta durante un período prolongado. Especialmente en entornos de computación distribuida/granja web.
5. Capacidad para manejar el primer desarrollo del código, crear y actualizar el esquema sin destruir los datos.
   • EF 4.1 parece ser deficiente en este sentido, aunque 4.3 es un salto y atado mejor. También me gustó la anotación de datos mejor que separar las clases de mapeo en NH. Me imagino que puedo enviar la clase y desde allí poder crear un modelo de persistencia sin ampliar el método para las clases de asignación.
6. Soporte para el patrón IRepository
7. Soporte para LINQ
   • Algo atado a (6) anteriores Quiero realmente un buen soporte para LINQ. No quiero que los desarrolladores porquería alrededor con la implementación a nivel más bajo y conseguir nosotros mismos pegado a un particular ORM
8. Rendimiento
9. apoyo para las operaciones CRUD mayor, sin tener que cargar los datos en la capa de aplicación. P.ej. Quiero incrementar todas las filas de una columna de una tabla en particular por 1. No quiero cargar esto en la memoria e incrementar las filas una por una. Esto sería una locura para una operación tan simple. Linq2Sql solía tener Magiq para manejar este tipo de cosas, ¿qué NH y EF tienen?
10. Almacenamiento en caché, carga ansiosa, carga lenta, propiedades de navegación.
    • Déjame ser sincero Odio estas cosas cuando se hace implícitamente. La razón es que es difícil distinguir lo que se almacena en caché, añejo de lo nuevo. En EF, generalmente dejo todas las propiedades de navegación, porque no quiero que estas propiedades se carguen con las 5 principales, porque eso es lo que necesita la operación actual, pero más adelante en la secuencia, otro desarrollador intenta hacer un conteo que será inexacto.
    • Así que mi política personal: todas las SOA serán apátridas a menos que exista una buena razón en caso contrario. Si necesita referenciar datos, obténgalo de la persistencia. Será más lento, pero el código será más legible y flexible.
    • De forma similar para el almacenamiento en caché. Es bastante complejo ya que está en un entorno distribuido, quiero que todo el almacenamiento en caché sea muy explícito. Si un desarrollador desea codificar contra el caché, debería hacerlo, no codificar contra el ORM, y hacer que parezca que está extrayendo datos recientes de la persistencia cuando en realidad está obteniendo datos obsoletos.
    • Ahora la pregunta es, ¿tiene NHibernate algún concepto/abstracción que haría que el almacenamiento en caché, la carga ansiosa/diferida sea mucho más explícita que la disponible actualmente en EF? En este caso, no me importa mucho la facilidad de desarrollo, me preocupo más por la claridad y la claridad.

Además no importa mucho para OSS vs argumento propietaria. El equipo no puede darse el lujo de echar un vistazo bajo el capó y comenzar a jugar con el código de otras personas. Me importa más el ángulo "simplemente funciona" que cualquier otra cosa.

Answer 1

Usted podría utilizar bltoolkit;) ->http://www.bltoolkit.net/Doc.Linq.ashx

Sólo toma 2 minutos para leer esto ->http://www.bltoolkit.net/Doc.LinqModel.ashx

Pero en

• muy buen soporte LINQ
• operaciones cortas DML (nr 9)
• gran rendimiento/soporte a granel
• gran SQL generado
• apoyo enumeración ;-)
• sin carga lenta/seguimiento entidad/almacenamiento en caché magia especial, ahora estas cosas que suele causar problemas
• No hay características mágicas -> menos abstracción -> menos fugas -> menos problemas -> menor curva de aprendizaje

por cierto lo hace nr 3, que tiene atributos TableFunction & TableExpression para apoyar con valores de tabla UDF, pistas, y otros alrededor de las decoraciones de mesa. para que pueda escribir sus propios métodos de extensión para usar en sus LINQ declaraciones por ejemplo

[TableExpression("{0} {1} WITH (TABLOCK)")] 
public Table<T> WithTabLock<T>() 
    where T : class 
{ 
    return _ctx.GetTable<T>(this, ((MethodInfo)(MethodBase.GetCurrentMethod())).MakeGenericMethod(typeof(T))); 
} 

y luego

using (var db = new TestDbManager()) 
{ 
    var q = 
     from p in new Model.Functions(db).WithTabLock<Parent>() 
     select p; 

    q.ToList(); 
} 

Muestra operación DML

db.Employee 
    .Where(e => e.Title == "Spectre") 
    .Set(e => e.Title, "Commander") 
    .Update(); 

Answer 2

Usted no quiere ninguno de ellos. No podrá especificar sugerencias de tablas arbitrarias, y no será tan flexible como desee.

Si todos estos son requisitos, no hay ORM en el planeta que los satisfaga.

EDIT:

Basado en su comentario. nHibernate le dará más poder, pero a costa de una mayor complejidad en la configuración de su modelo. Hay algunas herramientas que pueden ayudar, pero cada una tiene sus ventajas y desventajas.

EF es más fácil de configurar y usar, pero menos potente. nHibernate es lo opuesto. Tienes que elegir entre potencia y complejidad.

BTW, en lo que respecta a las operaciones masivas y qué no, simplemente puede emitir SQL directamente desde el marco para tales operaciones. O llama a un proceso almacenado.

Answer 3

Antes que nada, prefiero NHibernate bajo varios aspectos. Entity Framework también omite algo en la versión 5.0.

1. es muy fácil de añadir un nuevo tipo de NHibernate, por lo que si SQL Server 2012 tiene nuevos tipos que puede poner en práctica la relación dialecto/proveedor, pero la comunidad está siempre trabajando
2. sé que el equipo de NH es trabajando en el soporte de FW 4.5, EF supports desde el 5.0
3. Usando NH se puede hacer todo lo que quiere
4. NH apoya el método de mezcla para volver a conectar una entidad, EF también
5. EF no es compatible con las convenciones de nomenclatura, NH hace, También estoy escribiendo un auto mapeador basado en DataAnnotations, here el enlace a la versión anterior, espere 2 semanas para el nuevo
6. Utilizando NH o EF puede implementar la capa de datos con los patrones Repository y Unit of Work, también tengo que lanzar este paquete en NuGet
7. EF es totalmente compatible con LINQ, NH no pero se puede parchar utilizando una extensión point
8. Creo que los rendimientos están en el mismo nivel, NH mejor admite el caché de nivel secundario, por lo que es fácil evitar hits en la base de datos
9. NH tiene un lote mejorado support, no sé acerca de EF (especialmente el 5.0)
10. NH cuenta con una mejor aplicación de los puntos de extensión, por lo proxy/almacenamiento en caché/registro son de gran alcance de EF, pero en EF se puede escribir una wrapper a obtener lo que necesita

al final, con NH es más fácil para implementar el patrón DDD, porque el mapeo es más flexible.

Answer 4

sólo para añadir a otras respuestas ...

Ricardo Peres escribió una muy buena comparación, no sesgada de NHibernate y Marco de la entidad hace unos días. Podría ayudarte en tu investigación.

Se puede encontrar aquí: http://weblogs.asp.net/ricardoperes/archive/2012/06/07/differences-between-nhibernate-and-entity-framework.aspx

Answer 5

Mientras que escribí sobre algunas de estas cuestiones en another question, creo que vale la pena responder a esta un punto por punto.

1. Ambos son compatibles con todas las versiones de SQL Server
2. Ambos son compatibles con .NET 4.x. NH todavía apunta a 3.5, que no es un problema.
3. Ambos tienen manejo de transacciones. Ninguno admite sugerencias de consulta en los lenguajes de consulta nativos, pero ambos le permiten usar SQL.
4. Ambos le permiten volver a conectar entidades desconectadas. Personalmente, no creo que sea una buena práctica (prefiero pasar los DTO).
5. La migración del esquema es más madura y flexible en EF. El mapeo es mucho mejor en NH. Tiene soporte para mapear con atributos, que es mucho más poderoso que el equivalente de EF, que rápidamente encontrará que no admite ni siquiera las cosas básicas (como especificar la precisión de un campo decimal)
6. Puede implementar su Repositorio en la parte superior cualquiera de los dos.
7. Ambos admiten LINQ. EF admite una gama más amplia de consultas, a veces a costa de generar soluciones extremadamente ineficientes. No deberías embotar tus prácticas de desarrollo; cada método de consulta tiene sus ventajas y un buen desarrollador debe conocer las opciones.
8. El rendimiento es generalmente mejor con NH debido a su flexibilidad de mapeo y soporte para procesamiento por lotes, almacenamiento en caché y declaraciones DML
9. EF no admite operaciones masivas (DML).NH hace, usando INSERT/UPDATE/DELETE que son muy similares a las de SQL, pero en el modelo de objetos (por ejemplo, puede especificar las condiciones de uso de la sintaxis con punto en lugar de explícito se une)
10. • EF no soporta almacenamiento en caché, punto Hay algunas muestras no compatibles que no están listas para producción. Todo el almacenamiento en caché en NHibernate es explícito (usted especifica qué entidades, colecciones y consultas desea almacenar en caché, por cuánto tiempo, etc.). Admite cachés distribuidos como memcached, por lo que también puede ocuparse de los datos obsoletos del caché.
    • Ambas le permiten cargar referencias y colecciones explícitamente ansiosas. NH tiene, en mi opinión, un mejor diseño proxy, que no contamina su modelo con FK (este es un tema largo, puede publicar una pregunta de seguimiento si lo desea). Y, como siempre, TIENE más flexibilidad al especificar cómo se debe cargar cada relación.

En pocas palabras: NH es más flexible y mejor rendimiento, sin duda. EF tiene un mejor soporte de migración, una curva de aprendizaje un poco más fácil y un proveedor de LINQ más completo.