NHibernate HQL frente a CriteriaAPI frente a QueryOver frente a Linq.Actuación

Question

¿Cuáles son los actuación ¿Diferencias entre hql y criteriosApi y QueryOver?¿Hay situaciones en las que uno es más rápido o más lento que el otro?

Editar:Extendí la pregunta con QueryOver y Linq.

=============================================

Bueno, no estoy seguro de qué respuesta marcar como respuesta, así que marcaré las publicaciones con más VoteUp.No sé.En realidad, esto es más una discusión que una pregunta.

Answer 1

Las características de rendimiento entre ICriteria y HQL varían poco (no sé acerca de QueryOver) por una sencilla razón.

De forma predeterminada, las consultas de ICriteria intentarán implementar sus estrategias de recuperación tal como se definen en su mapeo, mientras que HQL de manera predeterminada considera todo Lazy y depende de sus declaraciones de unión dentro de su consulta para definir qué se recupera con entusiasmo o no.

Además, ICriteria depende del mapeo para el paso de parámetros, mientras que HQL permite tipos de parámetros explícitos, p.IQuery.SetInt32("fooParam", 5);

Lo que realmente importa es la capacidad de conexión de las consultas de ICriteria (consulte ICriteria.CreateCriteria().CreateCriteria(), etc.), donde el motor NH tendrá que resolver ICriteria e intentar generar el SQL más válido.

En el lado opuesto, probablemente sea más fácil predecir si una consulta HQL producirá resultados consistentes y, como tal, facilitará el uso de QueryCache.

De cualquier manera, la configuración se genera una vez con las definiciones de creación y mapeo de ISessionFactory y todo lo demás en la memoria, por lo que el rendimiento es bueno.

La generación de SQL real se realiza de manera diferente entre los dos y esa es la razón por la que no existe una utilidad para ICriteria -> HQL.

Al final, mi experiencia me ha demostrado que el rendimiento entre los 2 es probablemente el mismo más o menos en algunos milisegundos.

Como nota al margen, declarar tanto como sea posible en el mapeo dará como resultado una generación de SQL más concisa, así como una operación de NHibernate, por ejemplo, para propiedades de cadena que mapean el Length en .hbm.xml dará como resultado que NHibernate verifique las longitudes de las cadenas antes de ir a la base de datos.

Answer 2

En lo que respecta a QueryOver, esperaría que la actuación fuera idéntica a los criterios API, ya que se construye como una extensión de esa API.Por lo tanto, para consultas equivalentes en las dos API, esperaría que se genere la misma consulta de la base de datos.La única diferencia que he notado entre las interfaces de QueryOver y criterio es que encuentro que la interfaz de QueryOver es "limpiador" y más agradable para trabajar.

En mi experiencia, el criterio API ha recibido más "amor" que la interfaz HQL.Me he encontrado con los casos en que podía expresar ciertas consultas con la interfaz de criterios que no pude encontrar una forma equivalente de expresar en la interfaz HQL.

Con respecto al rendimiento, encuentro la forma en que se encuentra la consulta ", se le pregunta" tiene más rendimiento que la selección de Criteria API versus HQL versus QueryOver.Usaría la interfaz que le proporciona el ajuste más natural para su pensamiento.

Answer 3

QUERYOVER es un reemplazo muy bueno para los criterios en la mayoría de los respetos debido a la sintaxis mejorada y la seguridad del tipo. Sin embargo, se debe tener en cuenta que el procesamiento de las expresiones LAMBDA en el QUERYOVER puede ser costoso (y supongo que lo mismo se aplicaría para las consultas de Linq). Por lo tanto, al tiempo que ejecuta la consulta de SQL final no toma más tiempo que otros métodos (ICRITERIA, HQL), convertir el objeto de consulta a la consulta SQL apropiada.

Como ejemplo, hemos estado desarrollando una aplicación que ejecutaba cientos de consultas de QueryOver un segundo (usando ADO.NET SOPORTE DE LAS BACKING) y encontramos que las consultas a los icriterios casi duplicaron nuestra capacidad para ejecutar consultas y el uso de CPU a la mitad. . Supongo que la sobrecarga involucrada en el procesamiento de la expresión de lambda se puede reducir mucho si usa el caché de segundo nivel y el almacenamiento en caché de consulta; Pero como esto no es adecuado para nuestra aplicación, no lo he hecho yo mismo.

Con respecto a su pregunta más general sobre la cual es más rápida: realmente depende. La única forma segura de despedir es ejecutando una herramienta de perfiles (NHPROF trabaja maravillas para escenarios como este). Pero en general, HQL es el más cercano a SQL y, por lo tanto, lo más flexible, lo que le permite un poco más de alcance optimizar sus consultas. Sin embargo, para la gran mayoría de las consultas simples de complejidad intermedias, hay poca o ninguna diferencia entre los icriterios y la HQL. Y las consultas de los icriterios son mucho más fáciles de trabajar con si sus consultas se construyen dinámicamente.

Answer 4

Aún no he encontrado alguna diferencia entre los dos.Dicho esto: HQL tiene funcionalidad que no está disponible en los criterios-API.

sobre todo es una cuestión de estilo y preferencia personal si usa el primero o este último.Y la traducción de su consulta a SQL no tiene en cuenta mucho cuando se trata de consultar.

de las personas que saben más que yo: http://ayende.com/blog/archive/2009/06/01/nhiberNate-Ceries-Ndash-Should-i--HQl-Or-R-Riteria.aspx