¿Dónde está la referencia api para nhibernate?

Question

Puedo ir mental, pero no puedo encontrar ningún material de referencia de API para nhibernate. He encontrado muchos manuales, tutoriales, libros electrónicos, etc., pero no hay referencias de API. Vi el archivo chm en la página nhibernate sourceforge, pero parece que no funciona en ninguno de mis PC (diferentes sistemas operativos)

¿Puede alguien indicarme la dirección correcta?

Answer 1

no es un buen libro que abarca una gran cantidad, y no es la documentación HTML en el sitio (que también se presenta como un libro)

(el libro estaría manejando - NHibernate en Acción - un poco anticuado, pero un buen comienzo)

Aquí está el link a la referencia en línea

Answer 2

Acabo de encontrar esta:

http://web.archive.org/web/20141001063046/http://elliottjorgensen.com/nhibernate-api-ref/index.html

No parece ser oficial, pero al menos parece como una referencia API ... a diferencia de la referencia oficial, que en su mayoría describe conceptos y mapeos sin ninguna información sobre clases y miembros.

Answer 3

Si está en Windows, obtenga ILSpy y apúntelo a NHibernate.dll. No es exactamente lo mismo que la documentación real de API, pero no es tan mala.

Answer 4

No hay referencias de clase públicamente disponibles en Internet hasta donde yo sé. Puedes construirlo desde la fuente. Clone them, ejecute ShowBuildMenu.bat para configurar el origen (creación de depuración), luego vaya a la carpeta doc, asegúrese de que tenga los requisitos previos indicados en el archivo reference\readme.txt y ejecute nant doc. Esto generará la referencia de clase en la carpeta build.

lo contrario, el API más comúnmente utilizados no son de ancho, y la mayoría de ellos son xml documentado con intellisens de trabajo en Visual Studio. El reference documentation tiene la ventaja de dar más contexto, probablemente ayudar a evitar trampas como creer ISession.Update se va a utilizar para la actualización de las entidades (esto es un error, que no lo necesita a menos que utilice entidades separadas, o entidades procedentes de otra sesión).

Oficial documentation reference está en http://nhibernate.info.

Sub-enlaces:

• Global documentation list
• Reference (Lo que yo utilizo sobre todo, sobre todo después de piezas sub.)
  • Configuration
  • Mapping - basic/entities. (Añadir asignación de archivo xsd definición en cualquiera o en las carpetas de la solución para dejar VS conocerla y darle intellisens en sus asignaciones de HBM.)
  • Mapping - collections
  • Querying - general. No se pierda la función de consultas nombradas en 9.3.2.
  • API de Consulta de:
    1. HQL. Uso principalmente HQL con consultas con nombre, en mapeos, para consultas no construidas dinámicamente. Se analizan y validan al crear una fábrica de sesión, lo que normalmente ocurre al inicio de la aplicación, por lo que es casi tan buena como la validación del tiempo de compilación. Comprueba los registros de log4net para obtener los motivos detallados de las fallas de análisis de consultas nombradas.
    2. Criteria API. Lo veo como la forma histórica de construir dinámicamente consultas en código, para ser preferible a la construcción de cadenas HQL.
    3. QueryOver API. Basado en Criteia API, con soporte de expresión lambda para tener validación en tiempo de compilación de nombres de entidades consultadas. Debería ser preferido sobre Criteria API en mi opinión.
    4. Linq API. Ideal para consultas dinámicas. Tenga en cuenta que su implementación traduce sus consultas a HQL. Con consultas complejas, puede generar construcciones HQL no compatibles. Tener conocimiento de las capacidades HQL permite una mejor comprensión de cómo escribir una consulta Linq compatible para casos complejos. (Por ejemplo, para una orden compleja por, utilice mejor una subconsulta de linq explícita en el OrderBy en lugar de usar una colección mapeada en la entidad consultada.)
    5. Native SQL. Bueno, bastante claro. Para usar con el ejemplo cuando necesite alguna característica especial de SQL no disponible a través de otras API de consulta (SQL Server de texto completo, seleccione para xml, ...), y que no desea extender esas otras API. También puede llamar a procedimientos almacenados. Cuando uso SQL nativo, prefiero las consultas SQL.
  • Modifying data, §9.4 a través de 9,7 + 9,9
  • Performances.
    1. Batch fetching. Acerca de esto, puede leer my post here para obtener una explicación detallada de por qué la carga diferida puede ser muy eficiente con NHibernate, gracias a la recuperación de lotes. Esta característica única siempre me hará preferir NHibernate a Entity Framework, hasta que deje de carecer de EF.
    2. Second level cache. Otra gran característica de NHibernate, que carece de soporte nativo en EF. Tenga cuidado, debe usar transacciones para aprovechar esto. Permite a NHibernate desalojar automáticamente las entradas almacenadas en la memoria caché a medida que cambia los datos a través de su proceso de solicitud. Sin transacciones, NHibernate deshabilitará el caché de segundo nivel tan pronto como comience a cambiar los datos, para evitar dejar que el caché genere datos obsoletos.
  • Interceptors. Esta es una forma entre muchas que permite personalizar el funcionamiento interno de NHibernate. NHibernate es muy fuerte al permitir que lo extiendas. También puede agregar sus propias extensiones HQL como here, su propia extensión linq2NH como here (todas son respuestas mías). Y hay otras formas, vea esto list para las soluciones de extensibilidad linq2NH.
• Hibernate documentation. NHibernate se deriva de Hibernate, pero su documentación puede estar un poco retrasada con respecto a las asignaciones. Puedo ir allí para las propiedades de mapeo que encontré en la definición de hbm.xml xsd, pero que no están documentadas en el lado de NHibernate. En el lado de Hibernate, la documentación de mapeo hbm se encuentra en versiones anteriores, la documentación más nueva se centra más en JPA, que es específica de Java.

Por otra parte, una referencia de clase muy probablemente estará cerca del Hibernate one. Hay tantas API internas que apoyan su implementación que no es muy útil.

¿Por qué tales API no están ocultas (internas, privadas, ...)? No ocultarlos es necesario para permitir las grandes capacidades de extensibilidad de NHibernate. Esas capacidades son imprescindibles en mi opinión. Por el contrario, es tan difícil solucionar algunas otras deficiencias del proyecto .Net, debido a la falta de extensibilidad que sufren. (MVC FileResult and the TweakDispositionAsInline Tuve que usar en lugar de simplemente sobrescribir algún método, o intentar extender linq-to-entities, ver this.)