Gdzie jest odwołanie do api dla nhibernate?

Question

Może mam zamiar być mentalny, ale nie mogę znaleźć żadnego materiału referencyjnego dla nhibernate. Znalazłem mnóstwo podręczników, samouczków, książek elektronicznych itp., Ale nie ma odniesienia do api. Widziałem plik chm na stronie nhibernate sourceforge, ale nie działa on na żadnym z moich komputerów (różne systemy operacyjne)

Czy ktoś może wskazać mi właściwy kierunek?

Answer 1

istnieje dobra książka, która obejmuje wiele i nie ma dokumentacji HTML na stronie (który także jest w formie książkowej)

(książka byłaby załogi - nHibernate w działaniu - trochę przestarzałe, ale to dobry początek)

Oto link do odniesienia internetowym

Answer 2

właśnie znalazłem ten:

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

To nie wydaje się być oficjalne, ale przynajmniej jest to wygląda jak odniesienie API ... w przeciwieństwie do oficjalnego odniesienia, które w większości opisuje pojęcia i mapowania bez żadnych informacji o klasach i członkach.

Answer 3

Jeśli jesteś w systemie Windows, pobierz ILSpy i wskaż go w NHibernate.dll. Nie jest to tak samo jak prawdziwa dokumentacja API, ale nie jest aż tak źle.

Answer 4

W Internecie nie ma publicznie dostępnych odniesień do klas, o ile wiem. Możesz go zbudować ze źródła. Clone them, uruchom ShowBuildMenu.bat, aby skonfigurować źródło (kompilację debugowania), a następnie przejdź do folderu doc, upewnij się, że masz wymagania wstępne wskazane w pliku reference\readme.txt i uruchom nant doc. Spowoduje to wygenerowanie odwołania do klasy w folderze build.

W przeciwnym razie najczęściej używane API nie są szerokie, a większość z nich to xml udokumentowany przez intellisens działający w Visual Studio. Atrybut reference documentation ma tę zaletę, że daje więcej kontekstu, prawdopodobnie pomagając uniknąć pułapek, takich jak przekonanie, że ISession.Update ma być używany do aktualizowania encji (jest to niepoprawne, nie jest potrzebne, chyba że korzystasz z oddzielnych elementów lub jednostek pochodzących z innej sesji).

Oficjalna documentation reference jest na http://nhibernate.info.

Sub-linki:

• Global documentation list
• Reference (Co ja najczęściej korzystają, zwłaszcza po części sub.)
  • Configuration
  • Mapping - basic/entities. (Dodaj mapowanie pliku definicji XSD w dowolnych lub folderów rozwiązanie dla pozwalając VS wiem to i daje intellisens w swoim odwzorowań HBM.)
  • Mapping - collections
  • Querying - general. Nie przegap funkcji nazwanych zapytań w 9.3.2.
  • odpytywanie API:
    1. HQL. Używam głównie HQL z nazwanymi zapytaniami, w mapowaniach, dla zapytań, które nie są budowane dynamicznie. Są one przetwarzane i sprawdzane podczas budowania fabryki sesji, co zwykle ma miejsce przy starcie aplikacji, więc jest prawie tak dobre, jak sprawdzanie poprawności w czasie kompilacji. Sprawdza dzienniki log4net, aby uzyskać szczegółowe informacje o przyczynach niepowodzenia analizy nazwanych zapytań.
    2. Criteria API. Uważam to za historyczny sposób dynamicznego budowania zapytań w kodzie, aby być lepszym od konstrukcji łańcuchów HQL.
    3. QueryOver API. Oparte na Criteia API, z obsługą wyrażania lambda do sprawdzania poprawności kompilacji nazw indeksowanych podmiotów. Powinien być moim zdaniem preferowany w stosunku do API Criteria.
    4. Linq API. Doskonały do ​​dynamicznie budowanych zapytań. Pamiętaj, że jego implementacja przekłada twoje zapytania na HQL. W przypadku złożonych zapytań może generować nieobsługiwane konstrukcje HQL. Posiadanie wiedzy na temat funkcji HQL pozwala lepiej zrozumieć, jak napisać obsługiwane zapytanie Linq dla złożonych przypadków. (Na przykład, dla złożonego zamówienia, lepiej użyj jawnej pod-zapytania linq w OrderBy zamiast korzystać z kolekcji odwzorowanej na twój obiekt z zapytaniem).
    5. Native SQL. Cóż, dość oczywiste. Do użycia przez przykład, gdy potrzebujesz jakiejś specjalnej funkcji SQL niedostępnej w innych interfejsach API zapytań (pełny tekst serwera SQL, wybierz dla xml, ...) i nie chcesz rozszerzać tych innych API. Możesz również wywołać procedury składowane. Korzystając z natywnego kodu SQL, preferuję kwerendy o nazwach SQL.
  • Modifying data, §9.4 przez 9,7 + 9,9
  • Performances.
    1. Batch fetching. W związku z tym możesz przeczytać my post here, aby uzyskać szczegółowe wyjaśnienie, dlaczego leniwy ładowanie może być bardzo efektywne dzięki funkcji NHibernate, dzięki pobieraniu wsadowym. Ta pojedyncza funkcja zawsze powoduje, że wolę NHibernate over Entity Framework, aż przestanie brakować EF.
    2. Second level cache. Kolejna świetna funkcja NHibernate, pozbawiona natywnego wsparcia w EF. Uważaj, musisz użyć transakcji, aby to wykorzystać. Umożliwia on NHibernate automatyczne usuwanie wpisów z pamięci podręcznej w trakcie zmiany danych w procesie aplikacji. Bez transakcji NHibernate wyłącza pamięć podręczną drugiego poziomu, gdy tylko zaczniesz zmieniać dane, aby uniknąć sytuacji, w której pamięć podręczna da ci nieaktualne dane.
  • Interceptors. Jest to jeden z wielu sposobów pozwalających na dostosowanie pracy wewnętrznej NHibernate. NHibernate jest bardzo silny, pozwalając ci go przedłużyć. Możesz również dodać własne rozszerzenia HQL jako here, własne rozszerzenie linq2NH jako here (wszystkie są odpowiedziami ode mnie). Istnieją również inne sposoby, zobacz te list dla rozwiązań rozszerzalności linq2NH.
• Hibernate documentation. NHibernate pochodzi z Hibernate, ale jego dokumentacja może pozostawać w tyle za mapowaniem. Mogę tam poszukać właściwości mapowania, które znalazłem w definicji hbm.xml xsd, ale które nie są udokumentowane po stronie NHibernate. Po stronie hibernacji dokumentacja mapowania hbm znajduje się w starszych wersjach, nowsza dokumentacja koncentruje się bardziej na JPA, który jest specyficzny dla języka Java.

Co więcej, odwołanie do klasy najprawdopodobniej będzie znajdować się w pobliżu Hibernate one. Jest tak wiele wewnętrznych API, które wspierają jego implementację, która nie jest zbyt użyteczna.

Dlaczego takie API nie są ukryte (wewnętrzne, prywatne, ...)? Nie ukrywanie ich jest wymagane, aby umożliwić duże możliwości rozszerzalności NHibernate. Te możliwości są moim zdaniem niezbędne. W przeciwieństwie do tego, tak trudno jest naprawić niektóre inne niedociągnięcia projektu .Net, ze względu na braki rozszerzalności, na które cierpią. (MVC FileResult and the TweakDispositionAsInline Musiałem użyć zamiast być w stanie nadpisać niektóre metody, lub spróbować przedłużyć linq-to-entities, patrz this.)