LINQ vs Lớp truy cập dữ liệu


10

Tôi đã tự dạy mình luôn luôn xử lý bất kỳ mã truy cập dữ liệu nào trong một 'lớp' hoàn toàn riêng biệt với mã giao diện người dùng và logic nghiệp vụ của tôi. Đây luôn là một kiến ​​trúc rất tốt đối với tôi và bất kỳ 'quy tắc' hay thực tiễn tốt nhất nào tôi thấy, vẫn có thể phù hợp với phong cách mã hóa này, đặc biệt là Nguyên tắc Trách nhiệm Đơn lẻ .

Đối với hầu hết các dự án nhà của tôi, tôi sử dụng ORM do chính tôi tạo ra, thứ mà tôi luôn có ý định tạo nguồn mở. Tuy nhiên, kể từ đó, LINQ trở nên khả dụng, rất giống với cách ORM của tôi hoạt động (nhưng .. tốt hơn).

Không có gì mà trước đây tôi có thể làm với ORM của riêng mình mà bây giờ tôi không thể làm với LINQ (ngoại trừ các bit của tích hợp REST). Vì vậy, câu hỏi của tôi là; LINQ là lớp truy cập dữ liệu mới của tôi? Tôi có cần lớp này nữa không? BLL của tôi có nên nói chuyện trực tiếp với LINQ không? Hay là thực hành xấu này vẫn còn?

Biên tập:

Câu hỏi ban đầu được đề cập đến LINQ to Entities, nhưng có nhiều câu trả lời thú vị liên quan đến LINQ to SQL. Suy nghĩ của mọi người về cả hai là gì? Tôi tập hợp hơn LINQ to SQL thực sự không thể thay thế DAL, nhưng Entity Framework có thể không?

Câu trả lời:


7

Mặc dù bạn chỉ có thể đặt các truy vấn LINQ trong BLL của mình nhưng điều này có thể dẫn đến sao chép mã. Tôi vẫn sẽ tạo các kho lưu trữ sẽ là một trình bao bọc cho các truy vấn LINQ. Điều này sẽ tách mã Cơ sở dữ liệu khỏi mã BLL và sẽ hữu ích khi bạn quyết định sửa đổi mã truy cập dữ liệu của mình (nghĩa là chuyển sang Dapper hoặc truy vấn được biên dịch trước).

Nó cũng sẽ giúp kiểm tra đơn vị , vì các kho lưu trữ có thể dễ dàng bị chế giễu.


6

Bạn vẫn có thể có DAL, chỉ có điều nó có thể sử dụng LINQ to SQL thay vì những gì bạn đã sử dụng trước đó. Đó là cách tôi làm điều đó. Đừng khiến BLL của bạn trực tiếp sử dụng LINQ to SQL để truy cập dữ liệu.


Tôi đồng ý, LINQ to SQL chỉ là một ngôn ngữ truy vấn có thể ngăn bạn viết rất nhiều mã hệ thống ống nước. Nó không đóng gói quyền truy cập dữ liệu trong ứng dụng của bạn như DAL nên.
neontapir

Tôi đã đề cập đến LINQ cho các Thực thể. Tôi cũng sử dụng nhiều LINQ cho các đối tượng nhưng tôi coi đó là logic kinh doanh. Tôi hiểu sự khác biệt đằng sau hậu trường giữa Thực thể và LINQ với SQL, nhưng tôi chưa bao giờ sử dụng LINQ với SQL. Có sự khác biệt nào trong cú pháp không?
Connell

2

Linq không phải là về truy cập dữ liệu, bạn có thể sử dụng linq đối với bất kỳ IEnumerable.

Bạn đã thử thiết kế ứng dụng của mình mà không nghĩ về cơ sở dữ liệu lúc đầu chưa? Đó là, thực hiện ứng dụng của bạn và sử dụng một số loại kho lưu trữ. Sau đó, bạn sử dụng bất kỳ kỹ thuật để thực hiện các kho lưu trữ. Bằng cách đó, bạn có một giải pháp hoàn toàn tách rời, nơi bạn có thể bổ sung bất kỳ lớp truy cập dữ liệu nào bạn muốn.

Trong lớp truy cập dữ liệu đó, bạn có thể sử dụng ORM của riêng mình hoặc bạn có thể sử dụng Linq để sql, điều đó không quan trọng miễn là lớp truy cập dữ liệu thực hiện các kho lưu trữ mà bạn đã xác định.


1

Trừ khi bạn muốn "lớp logic nghiệp vụ" của mình giải quyết các giao dịch và hiệu năng truy vấn, vẫn cần có DAL.

LINQ làm cho khai báo truy vấn một quá trình thiết kế (hay còn gọi là trình biên dịch đã kiểm tra).

Các nhà cung cấp truy vấn LINQ (như LinqToSql và LinqToEntities) vẫn thực hiện chuyển đổi thời gian chạy của các truy vấn được khai báo thành văn bản sql. Sau đó, DBMS vẫn thực hiện giải thích truy vấn thời gian chạy, tạo kế hoạch truy vấn thời gian chạy, v.v.

Đây chỉ là một phần nhỏ của DAL.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.