Насколько я знаю, в Интернете нет общедоступных ссылок на классы. Вы можете построить его из источника. Клонируйте их , создайте решение 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 запросов:
- HQL . В основном я использую HQL с именованными запросами, в отображениях, для запросов, которые не создаются динамически. Они анализируются и проверяются при построении фабрики сеансов, что обычно происходит при запуске приложения, так что это почти так же хорошо, как проверка времени компиляции. Проверяет журналы log4net, чтобы получить подробные причины ошибок разбора именованных запросов.
- Критерии API . Я рассматриваю это как исторический способ динамического построения запросов в коде, который предпочтительнее создания строк HQL.
- API QueryOver . Основан на Criteia API, с поддержкой лямбда-выражений для проверки правильности именования запрашиваемых сущностей во время компиляции. На мой взгляд, предпочтительнее Criteria API.
- Linq API . Отлично подходит для динамически создаваемых запросов. Имейте в виду, что его реализация переводит ваши запросы в HQL. При сложных запросах он может генерировать неподдерживаемые конструкции HQL. Знание возможностей HQL позволяет лучше понять, как написать поддерживаемый запрос Linq для сложных случаев. (Например, для сложного порядка лучше использовать явный подзапрос linq в
OrderBy, а не использовать коллекцию, сопоставленную с запрашиваемой сущностью.)
- Собственный SQL . Ну, само собой разумеется. Используется в качестве примера, когда вам нужна какая-то особая функция SQL, недоступная через другие API запросов (полнотекстовый SQL-сервер, выберите xml, ...), и вы не хотите расширять эти другие API. Вы также можете вызвать хранимые процедуры. При использовании собственного SQL я предпочитаю именованные запросы SQL.
- Изменение данных , с Обновление объектов до Сброс и Обработка исключений .
- Представления .
- Пакетная загрузка . Об этом вы можете прочитать мой пост здесь для подробного объяснения того, почему отложенная загрузка может быть очень эффективной с NHibernate, благодаря пакетной загрузке. Эта единственная функция всегда заставляет меня предпочитать NHibernate, а не Entity Framework, пока в EF не исчезнет его.
- Кэш второго уровня . Еще одна замечательная функция NHibernate, в которой отсутствует встроенная поддержка EF. Остерегайтесь, вы должны использовать транзакции для использования этого. Это позволяет NHibernate автоматически удалять кэшированные записи для вас при изменении данных в процессе приложения. Без транзакций NHibernate отключит кэш второго уровня, как только вы начнете изменять данные, чтобы избежать того, что кеш даст вам устаревшие данные.
- перехватчики . Это один из многих способов настроить внутреннюю работу NHibernate. NHibernate очень сильно позволяет вам расширять его. Вы также можете добавить свои собственные расширения HQL как здесь , ваше собственное расширение linq2NH как здесь (все ответы от меня). И есть другие способы, см. Этот список для решений по расширению linq2NH.
Более того, ссылка на класс, скорее всего, будет рядом с Hibernate . Существует очень много внутренних API-интерфейсов, поддерживающих его реализацию, которые не очень удобны в использовании.
Почему такой API не скрыт (внутренний, закрытый, ...)? Не допускать их скрытия требуется для обеспечения широких возможностей NHibernate. Эти возможности должны быть на мой взгляд. Напротив, очень трудно исправить некоторые другие недостатки проекта .Net из-за недостатков расширяемости, от которых они страдают. (MVC FileResult и TweakDispositionAsInline, которые я должен был использовать вместо возможности переопределения какого-либо метода, или попробуйте расширить linq-to-entity , см. .)