Dove si trova il riferimento api per Nhibere?

Question

Forse sto andando mentalmente, ma non riesco a trovare alcun materiale di riferimento per api per l'inibizione. Ho trovato un sacco di manuali, tutorial, ebooks ecc ma nessun riferimento API. Ho visto il file chm sulla pagina sourceforge di nhibernate, ma non sembra funzionare su nessuno dei miei PC (SO diversi)

Qualcuno può indicarmi la giusta direzione?

Answer 1

c'è un buon libro che copre un sacco, e non v'è la documentazione html sul sito (che è disponibile anche come un libro)

(il libro sarebbe addette - NHibernate in azione - un po 'datata, ma un buon inizio)

Ecco l'link al riferimento on-line

Answer 2

ho appena trovato questo:

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

Non sembra essere ufficiale, ma almeno sembra come un riferimento API ... a differenza del riferimento ufficiale, che descrive principalmente concetti e mappature senza alcuna informazione su classi e membri.

Answer 3

Se sei su Windows, ottieni ILSpy e puntalo su NHibernate.dll. Non è esattamente la stessa documentazione API reale, ma non è male male.

Answer 4

Non ci sono riferimenti di classe pubblicamente disponibili su Internet per quanto ne so. Puoi costruirlo dalla fonte. Clona them, eseguire ShowBuildMenu.bat per impostare il sorgente (debug build), quindi passare alla cartella doc, assicurarsi di avere i prerequisiti indicati nel file reference\readme.txt ed eseguire nant doc. Ciò genererà il riferimento di classe nella cartella build.

In caso contrario, le API più comunemente utilizzate non sono ampie e la maggior parte di esse sono documentate in XML con intellisens che lavorano in Visual Studio. Lo reference documentation ha il vantaggio di dare più contesto, probabilmente aiutando a evitare le insidie ​​come credere che ISession.Update debba essere usato per aggiornare le entità (questo è sbagliato, non è necessario a meno che non si utilizzino entità distaccate o entità provenienti da un'altra sessione).

ufficiale documentation reference è http://nhibernate.info.

Sub-link:

• Global documentation list
• Reference (Quello che uso soprattutto, soprattutto dopo le parti secondarie.)
  • Configuration
  • Mapping - basic/entities. (Aggiungere file di definizione XSD di mapping in qualsiasi o cartelle soluzione per lasciare VS lo sanno e vi darà intellisens nel vostro mappature HBM.)
  • Mapping - collections
  • Querying - general. Non perdere la funzione di query denominata in 9.3.2.
  • API Interrogazione:
    1. HQL. Per lo più utilizzo HQL con query denominate, in mapping, per query non generate dinamicamente. Vengono analizzati e convalidati durante la creazione del factory di sessione, che normalmente si verifica all'avvio dell'applicazione, quindi è quasi buono come la convalida del tempo di compilazione. Controlla i log di log4net per ottenere i motivi dettagliati degli errori di analisi delle query con nome.
    2. Criteria API. Lo vedo come il modo storico di creare dinamicamente query nel codice, da preferire rispetto alla costruzione di stringhe HQL.
    3. QueryOver API. Basato su API Criteia, con supporto per espressioni lambda per la convalida del tempo di compilazione delle denominazioni delle entità interrogate. Dovrebbe essere preferito su Criteria API secondo me.
    4. Linq API. Ottimo per le query generate dinamicamente. Ricorda che la sua implementazione traduce le tue query in HQL. Con query complesse, può generare costrutti HQL non supportati. Avere conoscenza delle funzionalità HQL consente una migliore comprensione di come scrivere una query Linq supportata per casi complessi. (Ad esempio, per un ordine complesso, meglio utilizzare una sub-query esplicita di linq nello OrderBy piuttosto che utilizzare una raccolta mappata sull'entità interrogata.)
    5. Native SQL. Beh, abbastanza auto-esplicativo. Per essere utilizzato dall'esempio quando è necessaria una funzione speciale SQL non disponibile tramite altre API di interrogazione (SQL full-text server, selezionare per xml, ...) e che non si desidera estendere tali altre API. Puoi anche chiamare stored procedure. Quando utilizzo l'SQL nativo, preferisco le query denominate SQL.
  • Modifying data, §9.4 attraverso 9,7 + 9,9
  • Performances.
    1. Batch fetching. A questo proposito, è possibile leggere my post here per una spiegazione dettagliata del perché il caricamento lento può essere molto efficiente con NHibernate, grazie al recupero in batch. Questa singola funzione mi indurrà sempre a preferire NHibernate su Entity Framework, finché non cessa di mancare in EF.
    2. Second level cache. Un'altra grande funzionalità di NHibernate, senza supporto nativo in EF. Attenzione, è necessario utilizzare le transazioni per sfruttare questo. Permette a NHibernate di sfrattare automaticamente le voci memorizzate nella cache mentre modifichi i dati durante il processo di richiesta. Senza transazioni, NHibernate disabiliterà la cache di secondo livello non appena inizierai a modificare i dati, per evitare che la cache ti restituisca dati obsoleti.
  • Interceptors. Questo è uno dei modi in cui è possibile personalizzare il funzionamento interno di NHibernate. NHibernate è molto potente e ti consente di estenderlo. È inoltre possibile aggiungere le proprie estensioni HQL come here, la propria estensione linq2NH come here (tutte sono risposte da me). E ci sono altri modi, vedi questo list per le soluzioni di estensibilità linq2NH.
• Hibernate documentation. NHibernate deriva da Hibernate, ma la sua documentazione può essere un po 'indietro rispetto alle mappature. Potrei andare lì per le proprietà di mappatura che ho trovato nella definizione xsd hbm.xml, ma che non sono documentate sul lato NHibernate. Sul lato Hibernate, la documentazione di mappatura hbm si trova nelle versioni precedenti, la documentazione più recente si concentra maggiormente su JPA, che è specifico di Java.

Inoltre, un riferimento di classe sarà molto probabilmente vicino allo Hibernate one. Ci sono così tante API interne che supportano la sua implementazione che non è molto utilizzabile.

Perché tali API non sono nascoste (interne, private, ...)? Non è necessario nasconderli per consentire le eccellenti funzionalità di estensibilità di NHibernate. Queste capacità sono assolutamente indispensabili secondo me. Al contrario, è così difficile correggere alcune carenze del progetto .Net, a causa delle carenze di estensibilità che subiscono. (MVC FileResult and the TweakDispositionAsInline Ho dovuto usare invece di essere in grado di sovrascrivere qualche metodo, o provare ad estendere linq-to-entities, vedere this.)