NHibernate vs LINQ to SQL

Question

Là một người chưa từng sử dụng công nghệ trong các dự án trong thế giới thực, tôi tự hỏi liệu có ai biết hai cách này bổ sung cho nhau và bao nhiêu chức năng của chúng chồng lên nhau?

Answer 1

LINQ to SQL buộc bạn sử dụng mẫu bảng cho mỗi lớp. Lợi ích của việc sử dụng mẫu này là việc triển khai nhanh chóng và dễ dàng và sẽ tốn rất ít công sức để miền của bạn hoạt động dựa trên cấu trúc cơ sở dữ liệu hiện có. Đối với các ứng dụng đơn giản, điều này hoàn toàn có thể chấp nhận được (và đôi khi thậm chí thích hợp hơn), nhưng đối với các nhà phát triển ứng dụng phức tạp hơn thường sẽ đề xuất sử dụng mẫu domain driven design thay thế (đó là những gì NHibernate tạo điều kiện).

Sự cố với mẫu bảng cho mỗi lớp là cấu trúc cơ sở dữ liệu của bạn có ảnh hưởng trực tiếp đến thiết kế tên miền của bạn. Ví dụ, giả sử bạn có một bảng Customers với các cột sau để giữ thông tin địa chỉ chính của khách hàng:

• StreetAddress
• Thành phố
• Nhà nước
• Zip

Bây giờ, chúng ta hãy nói rằng bạn cũng muốn thêm cột cho địa chỉ gửi thư của khách hàng để bạn thêm các cột sau vào bảng Khách hàng:

• MailingStreetAddress
• MailingCity
• MailingState
• MailingZip

Sử dụng LINQ to SQL, đối tượng khách hàng trong tên miền của bạn bây giờ sẽ có các thuộc tính cho mỗi người trong số tám cột. Nhưng nếu bạn đang theo dõi một mẫu thiết kế điều khiển miền, có thể bạn đã tạo một lớp Địa chỉ và có lớp Khách hàng của bạn giữ hai thuộc tính Địa chỉ, một cho địa chỉ gửi thư và một cho địa chỉ hiện tại của chúng.

Đó là một ví dụ đơn giản, nhưng nó thể hiện cách thức mô hình bảng mỗi lớp có thể dẫn đến một miền hơi có mùi. Cuối cùng, nó tùy thuộc vào bạn.Một lần nữa, đối với các ứng dụng đơn giản chỉ cần chức năng CRUD cơ bản (tạo, đọc, cập nhật, xóa), LINQ to SQL là lý tưởng vì tính đơn giản. Nhưng cá nhân tôi thích sử dụng NHibernate vì nó tạo điều kiện cho một tên miền sạch hơn.

Chỉnh sửa: @lomaxx - Có, ví dụ tôi đã sử dụng là đơn giản và có thể đã được tối ưu hóa để hoạt động tốt với LINQ to SQL. Tôi muốn giữ nó càng cơ bản càng tốt để lái xe về nhà. Điểm vẫn còn mặc dù có một số kịch bản mà có cấu trúc cơ sở dữ liệu của bạn xác định cấu trúc tên miền của bạn sẽ là một ý tưởng tồi, hoặc ít nhất dẫn đến thiết kế OO suboptimal.

Answer 2

Bạn có thể làm rõ ý nghĩa của "LINQ" không?

LINQ không phải là công nghệ truy cập dữ liệu, nó chỉ là tính năng ngôn ngữ hỗ trợ truy vấn dưới dạng cấu trúc gốc. Nó có thể truy vấn bất kỳ mô hình đối tượng nào hỗ trợ các giao diện cụ thể (ví dụ: IQueryable).

Nhiều người tham khảo LINQ to SQL là LINQ, nhưng điều đó hoàn toàn không chính xác. Microsoft vừa phát hành LINQ To Entities với .NET 3.5 SP1. Ngoài ra, NHibernate có một giao diện LINQ, vì vậy bạn có thể sử dụng LINQ và NHibernate để lấy dữ liệu của bạn.

Answer 3

Bởi LINQ, tôi giả sử bạn có nghĩa là LINQ to SQL vì LINQ, tự nó, không có cơ sở dữ liệu "goings on" liên kết với nó. Nó chỉ là một ngôn ngữ truy vấn có một tải trọng của đường syntac để làm cho nó trông SQL-ish.

Trong rất cơ bản các ví dụ cơ bản, NHibernate và LINQ to SQL dường như vừa giải được cùng một vấn đề. Một khi bạn nhận được vượt qua mà bạn sớm nhận ra rằng NHibernate đã hỗ trợ cho rất nhiều tính năng cho phép bạn tạo ra các mô hình miền thực sự phong phú. Ngoài ra còn có một dự án LINQ to NHibernate cho phép bạn sử dụng LINQ để truy vấn NHibernate theo cách tương tự như bạn sẽ sử dụng LINQ to SQL.

Answer 4

Hoặc bạn có thể sử dụng dự án Castle ActiveRecords. Tôi đã sử dụng nó trong một thời gian ngắn để mở rộng một số mã mới cho một dự án kế thừa. Nó sử dụng NHibernate và hoạt động trên mẫu bản ghi hoạt động (đáng ngạc nhiên với tên của nó tôi biết). Tôi đã không cố gắng, nhưng tôi giả sử rằng một khi bạn đã sử dụng nó, nếu bạn cảm thấy cần phải giảm xuống NHibernate hỗ trợ trực tiếp, nó sẽ không được quá nhiều để làm như vậy cho một phần hoặc tất cả các dự án của bạn.

Answer 5

@Kevin: Tôi nghĩ rằng vấn đề với ví dụ bạn đang trình bày là bạn đang sử dụng thiết kế cơ sở dữ liệu kém. Tôi đã nghĩ bạn sẽ tạo ra một bảng khách hàng và một bảng địa chỉ và chuẩn hóa các bảng. Nếu bạn làm điều đó bạn chắc chắn có thể sử dụng LINQ to SQL cho kịch bản bạn đang đề xuất. Scott Guthrie có một số great series of posts on using Linq To SQL mà tôi thực sự khuyên bạn nên kiểm tra. Tôi không nghĩ rằng bạn có thể nói LINQ và NHibernate bổ sung cho nhau vì điều đó có nghĩa là họ có thể được sử dụng cùng nhau, và trong khi điều này là có thể, bạn tốt hơn nhiều lựa chọn một và gắn bó với nó.

NHibernate cho phép bạn ánh xạ các bảng cơ sở dữ liệu của mình tới các đối tượng miền theo cách rất linh hoạt. Nó cũng cho phép bạn sử dụng HBL để truy vấn cơ sở dữ liệu.

LINQ to SQL cũng cho phép bạn để ánh xạ đối tượng tên miền của bạn đến cơ sở dữ liệu tuy nhiên nó sử dụng cú pháp truy vấn LINQ để truy vấn cơ sở dữ liệu

Sự khác biệt chính ở đây là cú pháp truy vấn LINQ là kiểm tra tại thời gian biên dịch bởi trình biên dịch để đảm bảo các truy vấn của bạn hợp lệ.

Một số điều cần lưu ý với LINQ là nó chỉ khả dụng trong .net 3.x và chỉ được hỗ trợ trong VS2008. NHibernate có sẵn trong 2.0 và 3.x cũng như VS2005.

Một số điều cần lưu ý với NHibernate là nó không tạo ra các đối tượng miền của bạn, cũng như không tạo ra các tệp ánh xạ. Bạn cần phải làm điều này bằng tay. LINQ có thể
tự động thực hiện việc này cho bạn.

Answer 6

Hai điểm đó đã bị bỏ qua cho đến nay:

• LINQ to SQL không làm việc với Oracle hoặc bất kỳ cơ sở dữ liệu ngoài SQLServer. Tuy nhiên, bên thứ ba cung cấp hỗ trợ tốt hơn cho Oracle, ví dụ: devArt's dotConnect, DbLinq, Mindscape's LightSpeed và ALinq. (Tôi không có bất kỳ kinh nghiệm cá nhân với những)

• Linq to NHibernate cho phép bạn sử dụng LINQ với một Nhiberate, vì vậy nó có thể loại bỏ một lý do không sử dụng.

Ngoài ra, fluent interface to Nhibernate mới dường như làm cho việc lập bản đồ của Nhibernate ít khó khăn hơn. (Loại bỏ một trong những điểm nỗi đau của Nhibernate)

---

Cập nhật

LINQ to Nhiberate là tốt hơn trong Nhiberate v3 mà bây giờ là trong alpha. Có vẻ như nhiberate v3 có thể xuất xưởng vào cuối năm nay.

Số Entity Frame Work tính đến .net 4 cũng bắt đầu giống như một tùy chọn thực.

Answer 7

Fluiber NHibernate có thể tạo tệp ánh xạ của bạn dựa trên các quy ước đơn giản. Không có XML-viết và mạnh mẽ đánh máy.

Gần đây tôi đã làm việc trên một dự án, nơi chúng tôi cần thay đổi từ LINQ to SQL thành NHibernate vì lý do hiệu suất. Đặc biệt, cách thức vật chất hóa các đối tượng của L2S có vẻ chậm hơn so với Ditto của NHibernate và việc quản lý thay đổi cũng khá chậm. Và có thể khó tắt quản lý thay đổi đối với các tình huống cụ thể khi không cần thiết.

Nếu bạn định sử dụng các thực thể của bạn bị ngắt kết nối khỏi kịch bản DataContext - trong WCF - bạn có thể gặp nhiều rắc rối khi kết nối chúng với DataContext lần nữa để cập nhật thay đổi. Tôi đã không có vấn đề với điều đó với NHibernate.

Điều tôi sẽ bỏ lỡ từ L2S chủ yếu là việc tạo mã giữ mối quan hệ cập nhật trên cả hai đầu của các thực thể. Nhưng tôi đoán có một số công cụ cho NHibernate để làm điều đó ra có quá ...

Answer 8

Khi bạn viết "cho một người không sử dụng một trong số họ" LINQ to SQL rất dễ sử dụng để bất kỳ ai có thể sử dụng nó dễ dàng Nó cũng hỗ trợ các thủ tục, giúp hầu hết thời gian. Giả sử bạn muốn lấy dữ liệu từ nhiều bảng rồi viết một quy trình và kéo thủ tục đó tới nhà thiết kế và nó sẽ tạo mọi thứ cho bạn, Giả sử tên thủ tục của bạn là "CUSTOMER_ORDER_LINEITEM", tìm nạp bản ghi từ cả ba bảng này

MyDataContext db = new MyDataContext(); 
List<CUSTOMER_ORDER_LINEITEMResult> records = db.CUSTOMER_ORDER_LINEITEM(pram1, param2 ...).ToList<CUSTOMER_ORDER_LINEITEMResult>(); 

bạn có thể sử dụng bạn hồ sơ đối tượng trong vòng lặp foreach là tốt, mà không được hỗ trợ bởi NHibernate

Answer 9

chúng ta hãy Đầu tiên tách hai điều khác nhau: Cơ sở dữ liệu người mẫu là quan tâm đến dữ liệu trong khi mô hình đối tượng là quan tâm đến các thực thể và mối quan hệ.

Lợi thế Linq-to-SQL là tạo nhanh các lớp ra khỏi giản đồ cơ sở dữ liệu để chúng có thể được sử dụng làm đối tượng bản ghi hoạt động (xem định nghĩa mẫu thiết kế bản ghi hoạt động).

Lợi thế NHibernate là cho phép sự linh hoạt giữa mô hình đối tượng và mô hình hóa cơ sở dữ liệu của bạn. Cơ sở dữ liệu có thể được mô hình hóa để phản ánh tốt nhất dữ liệu của bạn trong việc xem xét hiệu suất chẳng hạn. Mặc dù mô hình đối tượng của bạn sẽ phản ánh tốt nhất các yếu tố của quy tắc kinh doanh bằng cách sử dụng một phương pháp như Domain-Driven-Design. (xem Kevin Pang bình luận)

Với cơ sở dữ liệu kế thừa với quy ước đặt tên và/hoặc đặt tên kém thì Linq-to-SQL sẽ phản ánh cấu trúc và tên không mong muốn này cho các lớp của bạn. Tuy nhiên NHibernate có thể ẩn mớ hỗn độn này với những người lập bản đồ dữ liệu.

Trong các dự án trường xanh, nơi cơ sở dữ liệu có tên gọi tốt và độ phức tạp thấp, LINQ-to-SQL có thể là lựa chọn tốt.

Tuy nhiên bạn có thể sử dụng Fluent NHibernate với ánh xạ tự động cho cùng một mục đích này với ánh xạ theo quy ước. Trong trường hợp này, bạn không lo lắng về bất kỳ người lập bản đồ dữ liệu nào với XML hoặc C# và để NHibernate tạo lược đồ cơ sở dữ liệu từ các thực thể của bạn dựa trên một quy ước mà bạn có thể tùy chỉnh.

Mặt khác, đường cong học tập của LINQ-to-SQL nhỏ hơn NHibernate.