Entity Framework vs NHibernate: comprenda las similitudes y diferencias

[ad_1]

Mucho antes de que existiera Entity Framework (EF) Core, o cualquier otro Entity Framework para el caso, ya teníamos NHibernate. En este artículo, revisaré Entity Framework y NHibernate, que los une y los diferencia.

Historia de NHibernate y Entity Framework

NHibernate es un puerto de Java Hibernate, uno de los mapeadores relacionales de objetos (ORM) más antiguos y respetados. Existe desde 2003 y recientemente fue desarrollado íntegramente por la comunidad, sin un patrocinador o empresa paraguas. Siempre ha sido de código abierto bajo la GNU Lesser General Public License.

Entity Framework Core es la versión .NET Core del producto insignia de Microsoft que se lanzó en 2008. Al principio, formaba parte de .NET 3.5 SP1 y, como tal, tenía licencia para su uso gratuito, pero no había código fuente disponible. .disponible. Como parte de la iniciativa .NET Core, ahora se ha reconstruido completamente a .NET Core y, como parte de .NET Core, se ha puesto a disposición bajo la licencia MIT. Desde el principio estuvo estrechamente vinculado a las versiones .NET y Visual Studio.

NHibernate tenía algunas versiones:

• La versión 1 era la original y ofrecía características básicas; inicialmente no admitía genéricos, pero se introdujeron en una versión menor posterior; se ejecutó en .NET 1.1.
• La versión 2 abandonó el soporte para .NET 1.x.
• La versión 3 introdujo LINQ (.NET Language-Integrated Query) y QueryOver, así como la carga lenta de propiedades.
• Las versiones 3.2 y 3.3 introdujeron convenciones y configuraciones fluidas (locuaces), mapeo de visualización, mejoras en HQL (Hibernate Query Language) y generador de bytecode integrado.
• La versión 4 comenzó a apuntar a los conjuntos .NET 4 y BCL (Base Class Library), en lugar de a Iesi.Collections. Ahora usando Roslyn (.NET Compiler Platform).
• La versión 5 agregó programación asincrónica, soporte fijo de TransactionScope y mucha limpieza, incluida la eliminación de código obsoleto.
• La versión 5.1 trajo soporte para .NET Core

En cuanto al Entity Framework (EF):

• La versión 1 tenía una funcionalidad básica con flujos de trabajo que priorizaban primero el modelo y la base de datos, y se lanzó con .NET 3.5 Service Pack 1.
• La versión 4 vino con .NET 4 y soportó carga lenta, entidades de seguimiento automático, POCO (Objetos CLR antiguos simples) y modelos de generador (T4 – Text Template Transformation Toolkit).
• Las versiones 4.1 y 4.3 («Code First») introdujeron el modelo de desarrollo de código primero y una API mucho más limpia; fue el primero en distribuirse fuera del límite a través de NuGet. 4.3 migraciones introducidas.
• La versión 5 trajo tipos enumerados, tipos espaciales y soporte de funciones con valores de tabla.
• La versión 6 agregó interceptores, registro, operaciones asincrónicas, convenciones personalizadas y soporte para procedimientos almacenados para operaciones CRUD.
• .NET Core 1 se ha reescrito por completo y, como tal, no ofrecía todas las características de las versiones anteriores. Solo funcionalidad básica, más la arquitectura para admitir bases de datos no relacionales. Incluso agregó características interesantes como propiedades de sombra.
• .NET Core 1.1 trajo mapeo a campos, carga explícita, resistencia de conexión y algunas API previamente disponibles.
• .NET Core 2 introdujo sus propias entidades, filtros globales, el operador LIKE, el grupo de DbContext, consultas compiladas explícitamente, asignaciones de funciones escalares y clases de configuración de entidades autónomas.

Puede ver que Microsoft no ha estado exactamente inactivo, y han pasado muchas cosas desde el lanzamiento de EF 1. De hecho, la familia EF Core es casi completamente independiente del original, e incluso Code-First era completamente nuevo. aunque la versión original todavía estaba debajo.

Plataformas

NHibernate ahora admite .NET 4 y versiones posteriores que se ejecutan en Windows o plataformas donde Mono está disponible y, a partir de la versión 5.1 (lanzada hace unos días), también es compatible con .NET Core. No hay planes para admitir fuentes de datos que no sean bases de datos relacionales.

EF Core se ejecuta en .NET Core y, por lo tanto, en cualquier plataforma que lo admita. Se basa en un modelo de proveedor que teóricamente puede funcionar con cualquier tipo de fuente de datos, no solo relacional. Se está trabajando para Azure Cosmos DB y es probable que vengan otros.

Arquitectura

NHibernate se distribuye a través de NuGet como una única DLL, sin otras dependencias, a menos que necesitemos conjuntos ordenados, donde también necesitamos Iesi.Collections. Todo está integrado. Necesita el .NET Framework completo o .NET Core.

Entity Framework Core, por otro lado, consta de varias DLL, que se proporcionan en muchos paquetes NuGet. Lo bueno es que las dependencias de NuGet se incorporan según sea necesario, por lo que para SQL Server, solo necesita obtener Microsoft.EntityFrameworkCore.SqlServer. Está dirigido a .NET Core, por supuesto.

Internamente, ambos son bastante extensibles, con muchas partes móviles, algunas de las cuales pueden reemplazarse.

Entity Framework Core se basa en características de .NET Core, como el registro y la inyección de dependencias, y las aprovecha para modificar componentes internos. Casi todo se puede cambiar.

NHibernate no usa la inyección de dependencias y la forma de reemplazar cada servicio es bastante diferente de un servicio a otro. En general, no es tan extensible como EF Core.

En NHibernate, necesitamos crear una instancia de un objeto Configuration y, a partir de él, producir una Session Factory. Debe haber solo uno de ellos a la vez en una aplicación, ya que son relativamente «pesados». Desde una fábrica de sesiones, producimos sesiones, que son abstracciones ligeras que encapsulan una conexión ADO.NET. Todo se sigue de eso.

Con EF, solo debemos preocuparnos por el contexto de una base de datos; incluye toda la información de configuración y mapeo y expone todas las API para interactuar con la fuente de datos. Es un modelo mucho más simple, pero se puede argumentar que la separación de intereses en NHibernate es más eficiente.

Bases de datos compatibles

De fábrica, NHibernate admite más de 10 bases de datos y versiones diferentes, que incluyen:

• SQL Server (incluido Azure)
• SQL Server CE
• Base de datos Oracle (múltiples ediciones)
• Ingres
• PostgreSQL
• MySQL
• DB2
• Sybase
• Informix
• SQLite
• Pájaro de fuego
• Cualquiera que use ODBC (conectividad abierta de bases de datos) u OLE (vinculación e incrustación de objetos) DB

Microsoft proporciona proveedores solo para:

• SQL Server (incluido Azure)
• SQLite
• En la memoria

El proveedor de memoria es particularmente útil para escenarios de prueba unitaria. Se está trabajando para Cosmos DB (Document DB) y Oracle Database. Otros proveedores ya ofrecen proveedores para otras bases de datos, ya sea gratis o comercialmente.

Por supuesto, NHibernate tiene una ventaja aquí, ya que es mucho más fácil comenzar a trabajar en cualquier base de datos compatible.

Configuración y mapeos

Entity Framework Core usa una configuración fluida (basada en código) y asignaciones fluidas o basadas en atributos. Las convenciones integradas no se pueden reemplazar ni agregar en este momento.

NHibernate tiene XML y configuraciones y mapeos fluidos. También ofrece asignaciones de atributos a través del proyecto complementario NHibernate Attributes. Las convenciones personalizadas son muy poderosas en NHibernate, EF Core aún no las tiene, y eso es algo en lo que NHibernate es mejor ahora.

Ambos necesitan mapeos, en cualquier formato. Ambos pueden asignar miembros, propiedades o campos no públicos. Además, ambos tienen la noción de tipos de valor (entidades propiedad de EF, componentes de NHibernate). NHibernate puede asignar una propiedad o campo a un comando SQL personalizado.

Además, ambos admiten propiedades de sombra, es decir, entidades que forman parte del esquema de la base de datos, pero que no están asignadas en el modelo de clase. Con EF Core, incluso podemos consultarlos.

Herencia de tablas

NHibernate es totalmente compatible con los tres patrones de herencia de tablas «canónicos»:

EF Core solo puede vivir con jerarquía de tabla por clase / herencia de tabla única. Hay un ticket abierto para solucionarlo, pero no está en el guión.

Generación de clave primaria

Con respecto a las claves primarias, Entity Framework Core admite:

• Claves de IDENTIDAD generadas automáticamente en SQL Server y SQLite
• Cadenas en SQL Server 2012+
• Valores asignados manualmente

NHibernate, por otro lado, ofrece un conjunto mucho más rico, que incluye:

• Identidades de SQL Server / Sybase o valores de incremento automático en otras bases de datos
• Cadenas en cualquier base de datos que las admita
• El algoritmo alto-bajo independiente de la base de datos
• Alto-bajo basado en una secuencia
• Un generador basado en la hora actual.
• Varios tipos de GUID (identificadores globales únicos)
• Asignado manualmente

Consulta y modificaciones

EF Core solo tiene LINQ y SQL para realizar consultas. Sin inserciones, eliminaciones o actualizaciones fuertemente tipadas. Aún sin soporte para la agrupación en el lado de la base de datos, se solucionará en la próxima versión. No hay proyecciones para tipos que no son entidades.

NHibernate, por otro lado, ofrece:

• LINQ
• API de criterios (una implementación del estándar de objeto de consulta)
• QueryOver (criterios LINQ)
• HQL (SQL orientado a objetos)
• SQL

Todos admiten la paginación, como lo hace EF Core LINQ.

También es posible realizar actualizaciones, eliminaciones o inserciones sobre consultas LINQ, lo cual es muy bueno. Además, HQL es un gran lenguaje para consultar la base de datos de forma agnóstica; es similar a SQL e incluso puede actualizar, insertar o eliminar entradas. NHibernate puede diseñar para cualquier clase, no solo para tipos anónimos.

NHibernate puede utilizar procedimientos almacenados o SQL personalizado para cualquier tipo de operación. EF Core todavía carece de esto, que estaba presente en las versiones anteriores a Core.

NHibernate tiene futuro, lo que significa que se pueden poner en cola múltiples consultas, ejecutarlas en la base de datos y recuperarlas al mismo tiempo, para las bases de datos que la soportan (SQL Server, Oracle). Además, según la estrategia de generación de la clave principal, también es posible agrupar varios registros al mismo tiempo.

Ambos admiten consultas y modificaciones asincrónicas.

Lidiando con la competencia

Además de las transacciones, que son compatibles con todas las bases de datos relacionales y los principales ORM, algunas de ellas ofrecen características de concurrencia optimistas.

EF Core puede usar una columna ROWVERSION / TIMESTAMP en SQL Server, o cualquiera de una lista de columnas, al actualizar un registro.

NHibernate ofrece características más ricas, además de SQL Server ROWVERSION / TIMESTAMP, también puede usar motores de base de datos nativos como ORA_ROWSCN de Oracle, pero también marcas de tiempo o columnas de versión. También puede comparar todas las columnas modificadas.

EF Core aún no admite transacciones ambientales (TransactionScope), pero la próxima versión lo solucionará. NHibernate históricamente ha tenido problemas con TransactionScope, pero parece que ya están solucionados.

EF Core no puede bloquear registros explícitamente, pero NHibernate ofrece una API para eso.

Colecciones

Las colecciones en EF Core son simples: solo listas, lo que significa uno a varios. Todavía no hay apoyo para muchos para muchos.

En NHibernate contamos con:

• Bolsas de entidades: colecciones desordenadas con posible duplicación
• Conjuntos de entidades: sin duplicación, tal vez ordenados
• Listas: colecciones indexadas por un número
• Mapas: colecciones indexadas por cualquier columna o posiblemente otra entidad
• Matrices de tipo primitivo
• Colecciones de tipos primitivos o de valor (componentes en NHibernate)

Entonces, como puede ver, hay mucho más en NHibernate, no es solo decir que tenemos una colección. Se admiten asociaciones de uno a varios y de varios a varios.

Carga lenta y explícita

La versión actual de EF Core (2.0) no tiene carga lenta, solo carga explícita (usando la API) o carga rápida (al hacer una consulta LINQ) de entidades y colecciones asociadas. LA…

[ad_2]