Где ссылка api для nhibernate?

Ответ 1

есть хорошая книга, которая покрывает много, и на сайте есть html-документация (которая также входит в книгу)

(книга будет комплектоваться - nHibernate in Action - немного устаревшая, но хорошее начало)

Вот ссылка в онлайн-ссылку

Ответ 2

Я только что нашел это:

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

Он не кажется официальным, но по крайней мере он похож на ссылку API... в отличие от официальной ссылки, которая в основном описывает понятия и сопоставления без какой-либо информации о классах и членах.

Ответ 3

Если вы находитесь в Windows, получите ILSpy и укажите его в файле NHibernate.dll. Это не совсем то же самое, что и настоящая документация API, но это не так уж плохо.

Ответ 4

Насколько я знаю, в Интернете нет общедоступных ссылок на классы. Вы можете построить его из источника. Клонируйте их, создайте решение NHibernate.sln, затем перейдите в папку doc, убедитесь, что у вас есть предпосылки, указанные в reference\readme.txt, и запустите nant doc. Это создаст ссылку на класс в папке build.

В противном случае наиболее часто используемый API не является широким, и большинство из них представлены в формате xml с документами intellisens, работающими в Visual Studio. Преимущество справочной документации состоит в том, что она дает больше контекста, возможно, помогает избежать ловушек, таких как вера в то, что ISession.Update следует использовать для обновления сущностей (это неправильно, вам это не нужно, если вы не используете отдельные сущности или сущности, поступающие из другого сеанса),

Официальная ссылка на документацию на https://nhibernate.info.

Суб-ссылка:

• Глобальный список документации
• Ссылка (Что я в основном использую, особенно следующие подразделы.)
  • конфигурация
  • Картография - основные/сущности. (Добавьте файл определения сопоставления xsd в любую папку или папку вашего решения, чтобы сообщить об этом VS и дать вам intellisens в ваших отображениях hbm.)
  • Картография - коллекции
  • Запросы - общие. Не пропустите функцию именованных запросов в интерфейсе IQuery.
  • Запросы API:
    1. HQL. В основном я использую HQL с именованными запросами, в отображениях, для запросов, которые не создаются динамически. Они анализируются и проверяются при построении фабрики сеансов, что обычно происходит при запуске приложения, так что это почти так же хорошо, как проверка времени компиляции. Проверяет журналы log4net, чтобы получить подробные причины ошибок разбора именованных запросов.
    2. Критерии API. Я рассматриваю это как исторический способ динамического построения запросов в коде, который предпочтительнее создания строк HQL.
    3. API QueryOver. Основан на Criteia API, с поддержкой лямбда-выражений для проверки правильности именования запрашиваемых сущностей во время компиляции. Должно быть предпочтительнее, чем Criteria API, на мой взгляд.
    4. Linq API. Отлично подходит для динамически создаваемых запросов. Имейте в виду, что его реализация переводит ваши запросы в HQL. При сложных запросах он может генерировать неподдерживаемые конструкции HQL. Знание возможностей HQL позволяет лучше понять, как написать поддерживаемый запрос Linq для сложных случаев. (Например, для сложного порядка лучше использовать явный подзапрос linq в OrderBy а не использовать коллекцию, сопоставленную с запрашиваемой сущностью.)
    5. Родной SQL. Ну, само собой разумеется. Используется в качестве примера, когда вам нужна особая функция SQL, недоступная через другие API запросов (полнотекстовый SQL-сервер, выберите xml,...), и вы не хотите расширять эти другие API. Вы также можете вызвать хранимые процедуры. При использовании нативного SQL я предпочитаю именованные запросы SQL.
  • Изменение данных, от обновления объектов до очистки и обработки исключений.
  • Спектакли
    1. Пакетная загрузка. Об этом вы можете прочитать в моем посте здесь для подробного объяснения того, почему отложенная загрузка может быть очень эффективной с NHibernate, благодаря пакетной загрузке. Эта единственная функция всегда заставляет меня предпочитать NHibernate, а не Entity Framework, пока в EF не исчезнет недостаток.
    2. Кэш второго уровня. Еще одна замечательная особенность NHibernate, которой не хватает встроенной поддержки в EF. Осторожно, вы должны использовать транзакции для использования этого. Это позволяет NHibernate автоматически удалять кэшированные записи для вас при изменении данных в процессе приложения. Без транзакций NHibernate отключит кэш второго уровня, как только вы начнете изменять данные, чтобы избежать того, что кэш-память даст вам устаревшие данные.
  • Перехватчики. Это один из многих способов настроить внутреннюю работу NHibernate. NHibernate очень сильно позволяет вам расширять его. Вы также можете добавить свои собственные расширения HQL как здесь, ваше собственное расширение linq2NH как здесь (все ответы от меня). И есть другие способы, см. Этот список для решений по расширению linq2NH.

Более того, ссылка на класс, скорее всего, будет рядом с Hibernate. Существует очень много внутренних API-интерфейсов, поддерживающих его реализацию, которые не очень удобны в использовании.

Почему такой API не скрыт (внутренний, закрытый,...)? Не допускать их скрытия требуется для обеспечения широких возможностей расширения NHibernate. Эти возможности должны быть на мой взгляд. Напротив, очень трудно исправить некоторые другие недостатки проекта.Net из-за недостатков расширяемости, от которых они страдают. (MVC FileResult и TweakDispositionAsInline мне пришлось использовать вместо того, чтобы просто быть в состоянии переопределения какой - то метод, или попытаться продлить linq-to-entities, см это.)