Tham chiếu api cho nhibernate ở đâu?

Question

Tôi có thể sẽ phát triển tinh thần, nhưng tôi không thể tìm thấy bất kỳ tài liệu tham chiếu api nào cho nhibernate. Tôi đã tìm thấy rất nhiều hướng dẫn sử dụng, hướng dẫn, ebooks vv nhưng không có tham chiếu api. Tôi thấy tập tin chm trên trang sourceforge nhibernate, nhưng nó dường như không hoạt động trên bất kỳ máy tính cá nhân nào của tôi (OSes khác nhau)

Ai đó có thể vui lòng chỉ cho tôi đi đúng hướng không?

Answer 1

có một cuốn sách tốt mà bao gồm rất nhiều, và có tài liệu html trên trang web (mà cũng đi kèm như một cuốn sách)

(cuốn sách sẽ được Manning - nHibernate trong hành động - một chút lỗi thời, nhưng một sự khởi đầu tốt)

đây là link đến tham khảo trực tuyến

Answer 2

tôi chỉ thấy điều này một:

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

Nó không có vẻ là chính thức, nhưng ít nhất nó trông như tham chiếu API ... không giống như tham chiếu chính thức, chủ yếu mô tả khái niệm và ánh xạ mà không có bất kỳ thông tin nào về lớp học và thành viên.

Answer 3

Nếu bạn đang sử dụng Windows, hãy lấy ILSpy và trỏ vào NHibernate.dll. Nó không hoàn toàn giống như tài liệu API thực, nhưng nó không phải là một nửa xấu.

Answer 4

Không có tài liệu tham khảo lớp học nào có sẵn công khai trên Internet theo như tôi biết. Bạn có thể xây dựng nó từ nguồn. Sao chép them, chạy ShowBuildMenu.bat để thiết lập nguồn (gỡ lỗi xây dựng), sau đó đi vào thư mục doc, đảm bảo bạn có các điều kiện tiên quyết được chỉ ra trong tệp reference\readme.txt và chạy nant doc. Điều này sẽ tạo tham chiếu lớp trong thư mục build.

Nếu không, API được sử dụng phổ biến nhất không rộng và hầu hết trong số chúng là tài liệu xml có nội dung hoạt động trong Visual Studio. Các reference documentation có lợi thế của việc đưa ra bối cảnh nhiều hơn, có thể giúp tránh những cạm bẫy như tin ISession.Update được sử dụng để cập nhật các thực thể (điều này là sai, bạn không cần nó trừ khi bạn sử dụng các thực thể tách ra, hoặc các thực thể đến từ một phiên khác).

Official documentation reference là trên http://nhibernate.info.

Sub-link:

• Global documentation list
• Reference (Những gì tôi chủ yếu sử dụng, đặc biệt là sau phần phụ.)
  • Configuration
  • Mapping - basic/entities. (Thêm ánh xạ tập tin định nghĩa xsd trong bất kỳ hoặc thư mục giải pháp của bạn đã cho VS biết nó và cung cấp cho bạn intellisens trong ánh xạ hbm của bạn.)
  • Mapping - collections
  • Querying - general. Đừng bỏ lỡ tính năng truy vấn được đặt tên theo số 9.3.2.
  • Truy vấn API:
    1. HQL. Tôi chủ yếu sử dụng HQL với các truy vấn được đặt tên, trong ánh xạ, cho các truy vấn không được xây dựng động. Chúng được phân tích cú pháp và xác thực khi xây dựng nhà máy phiên, thường xảy ra khi khởi động ứng dụng, vì vậy nó gần như tốt như xác nhận thời gian biên dịch. Kiểm tra nhật ký log4net để biết các lý do chi tiết về các lỗi phân tích cú pháp truy vấn được đặt tên.
    2. Criteria API. Tôi xem nó như là cách lịch sử của xây dựng động các truy vấn trong mã, được ưa thích hơn việc xây dựng các chuỗi HQL.
    3. QueryOver API. Dựa trên API Criteia, với biểu thức lambda hỗ trợ cho việc xác nhận thời gian biên dịch của các tên thực thể được truy vấn. Nên được ưa thích hơn API tiêu chí theo ý kiến ​​của tôi.
    4. Linq API. Tuyệt vời cho các truy vấn được tạo động. Hãy nhớ rằng việc thực hiện của nó dịch các truy vấn của bạn thành HQL. Với các truy vấn phức tạp, nó có thể tạo ra các cấu trúc HQL không được hỗ trợ. Có kiến ​​thức về khả năng HQL cho phép hiểu rõ hơn về cách viết truy vấn LINQ được hỗ trợ cho các trường hợp phức tạp. (Ví dụ, đối với một đơn đặt hàng phức tạp, tốt hơn hãy sử dụng truy vấn phụ LINQ rõ ràng trong OrderBy thay vì sử dụng bộ sưu tập được ánh xạ trên thực thể được truy vấn của bạn.)
    5. Native SQL. Vâng, khá tự giải thích. Để được sử dụng bởi ví dụ khi bạn cần một số tính năng đặc biệt của SQL không có sẵn thông qua các API truy vấn khác (SQL toàn văn bản máy chủ, chọn cho xml, ...) và bạn không muốn mở rộng các API khác. Bạn cũng có thể gọi các thủ tục được lưu trữ. Khi sử dụng SQL nguyên gốc, tôi ưu tiên các truy vấn có tên SQL.
  • Modifying data, §9.4 qua 9,7 + 9,9
  • Performances.
    1. Batch fetching. Về điều này, bạn có thể đọc my post here để có giải thích chi tiết về lý do tải chậm có thể rất hiệu quả với NHibernate, nhờ vào việc tìm nạp hàng loạt. Tính năng đơn này sẽ luôn khiến tôi thích NHibernate hơn Entity Framework, cho đến khi nó không còn trong EF.
    2. Second level cache. Một tính năng NHibernate tuyệt vời khác, thiếu hỗ trợ gốc trong EF. Hãy cẩn thận, bạn phải sử dụng các giao dịch để tận dụng điều này. Nó cho phép NHibernate tự động gỡ bỏ các mục được lưu trong bộ nhớ cache cho bạn khi bạn thay đổi dữ liệu thông qua quá trình ứng dụng của bạn. Nếu không có giao dịch, NHibernate sẽ vô hiệu hóa bộ nhớ cache cấp thứ hai ngay sau khi bạn bắt đầu thay đổi dữ liệu, để tránh cho phép bộ nhớ cache mang lại cho bạn dữ liệu cũ.
  • Interceptors. Đây là một trong nhiều cách cho phép tùy chỉnh NHibernate bên trong làm việc. NHibernate rất mạnh mẽ cho phép bạn mở rộng nó. Bạn cũng có thể thêm phần mở rộng HQL của riêng bạn là here, phần mở rộng linq2NH của riêng bạn là here (tất cả đều là câu trả lời từ tôi). Và có nhiều cách khác, hãy xem số list cho các giải pháp mở rộng LINQ2NH này.
• Hibernate documentation. NHibernate có nguồn gốc từ Hibernate, nhưng tài liệu của nó có thể tụt lại sau một chút về ánh xạ. Tôi có thể đến đó để lập bản đồ thuộc tính tôi tìm thấy trong định nghĩa xb h.xml xsd, nhưng đó không phải là tài liệu trên bên NHibernate. Về phía Hibernate, tài liệu lập bản đồ hbm được tìm thấy trong các phiên bản cũ hơn, tài liệu mới hơn tập trung nhiều hơn vào JPA, đó là Java cụ thể.

Hơn nữa, tham chiếu lớp học rất có thể sẽ ở gần Hibernate one. Có rất nhiều API nội bộ hỗ trợ việc triển khai của nó mà không thể sử dụng được nhiều.

Tại sao API đó không bị ẩn (nội bộ, riêng tư, ...)? Không giấu chúng là cần thiết để cho phép khả năng mở rộng tuyệt vời của NHibernate. Những khả năng đó là phải có trong quan điểm của tôi. Ngược lại, rất khó để khắc phục một số thiếu sót khác của dự án .Net, do thiếu khả năng mở rộng mà chúng bị ảnh hưởng. (MVC FileResult and the TweakDispositionAsInline Tôi đã phải sử dụng thay vì chỉ có thể ghi đè một số phương pháp hoặc thử mở rộng linq-to-entities, xem this.)