LINQ-to-SQL so với các thủ tục được lưu trữ? [đóng cửa]

Tôi đã xem bài đăng "Hướng dẫn cho người mới bắt đầu về LINQ" tại đây trên StackOverflow ( Hướng dẫn cho người mới bắt đầu về LINQ ), nhưng đã có một câu hỏi tiếp theo:

Chúng tôi sắp sửa triển khai một dự án mới trong đó gần như tất cả các cơ sở dữ liệu của chúng tôi sẽ phục hồi dữ liệu khá đơn giản (có một phân đoạn khác của dự án đã ghi dữ liệu). Hầu hết các dự án khác của chúng tôi cho đến thời điểm này đều sử dụng các thủ tục được lưu trữ cho những thứ đó. Tuy nhiên, tôi muốn tận dụng LINQ-to-SQL nếu nó có ý nghĩa hơn.

Vì vậy, câu hỏi là: Đối với các truy xuất dữ liệu đơn giản, cách tiếp cận nào tốt hơn, LINQ-to-SQL hoặc các procs được lưu trữ? Bất kỳ pro hoặc con cụ thể?

Cảm ơn.

Một số ưu điểm của LINQ so với sprocs:

1. Loại an toàn : Tôi nghĩ tất cả chúng ta đều hiểu điều này.
2. Trừu tượng : Điều này đặc biệt đúng với LINQ-to-Entities . Sự trừu tượng hóa này cũng cho phép khung để thêm các cải tiến bổ sung mà bạn có thể dễ dàng tận dụng. PLINQ là một ví dụ về việc thêm hỗ trợ đa luồng cho LINQ. Thay đổi mã là tối thiểu để thêm hỗ trợ này. Sẽ khó khăn hơn nhiều để thực hiện mã truy cập dữ liệu này mà chỉ đơn giản là gọi sprocs.
3. Hỗ trợ gỡ lỗi : Tôi có thể sử dụng bất kỳ trình gỡ lỗi .NET nào để gỡ lỗi các truy vấn. Với sprocs, bạn không thể dễ dàng gỡ lỗi SQL và trải nghiệm đó phần lớn được gắn với nhà cung cấp cơ sở dữ liệu của bạn (MS SQL Server cung cấp trình phân tích truy vấn, nhưng thường thì điều đó không đủ).
4. Nhà cung cấp bất khả tri : LINQ hoạt động với rất nhiều cơ sở dữ liệu và số lượng cơ sở dữ liệu được hỗ trợ sẽ chỉ tăng lên. Sprocs không phải lúc nào cũng có thể di động giữa các cơ sở dữ liệu, do cú pháp hoặc hỗ trợ tính năng khác nhau (nếu cơ sở dữ liệu hỗ trợ sprocs).
5. Triển khai : Những người khác đã đề cập đến vấn đề này rồi, nhưng việc triển khai một bộ lắp ráp đơn giản hơn là triển khai một bộ sprocs. Điều này cũng liên kết với # 4.
6. Dễ dàng hơn : Bạn không phải học T-SQL để truy cập dữ liệu, bạn cũng không phải học API truy cập dữ liệu (ví dụ: ADO.NET) cần thiết để gọi các sprocs. Điều này có liên quan đến # 3 và # 4.

Một số nhược điểm của LINQ vs sprocs:

1. Lưu lượng truy cập mạng : sprocs chỉ cần tuần tự hóa dữ liệu tên sproc và đối số qua dây trong khi LINQ gửi toàn bộ truy vấn. Điều này có thể trở nên thực sự tồi tệ nếu các truy vấn rất phức tạp. Tuy nhiên, sự trừu tượng của LINQ cho phép Microsoft cải thiện điều này theo thời gian.
2. Ít linh hoạt hơn : Sprocs có thể tận dụng tối đa bộ tính năng của cơ sở dữ liệu. LINQ có xu hướng chung chung hơn trong hỗ trợ của nó. Điều này là phổ biến trong bất kỳ loại trừu tượng ngôn ngữ nào (ví dụ C # vs trình biên dịch).
3. Biên dịch lại : Nếu bạn cần thay đổi cách thức truy cập dữ liệu, bạn cần biên dịch lại, phiên bản và triển khai lại lắp ráp của bạn. Sprocs đôi khi có thể cho phép một DBA điều chỉnh thói quen truy cập dữ liệu mà không cần phải triển khai lại bất cứ điều gì.

Bảo mật và khả năng quản lý là điều mà mọi người tranh luận quá.

1. Bảo mật : Ví dụ: bạn có thể bảo vệ dữ liệu nhạy cảm của mình bằng cách hạn chế quyền truy cập trực tiếp vào các bảng và đặt ACL trên các sprocs. Tuy nhiên, với LINQ, bạn vẫn có thể hạn chế quyền truy cập trực tiếp vào các bảng và thay vào đó đặt ACL trên các chế độ xem bảng có thể cập nhật để đạt được kết thúc tương tự (giả sử cơ sở dữ liệu của bạn hỗ trợ các chế độ xem cập nhật).
2. Khả năng quản lý : Sử dụng các khung nhìn cũng mang lại cho bạn lợi thế trong việc che chắn ứng dụng của bạn không phá vỡ các thay đổi lược đồ (như chuẩn hóa bảng). Bạn có thể cập nhật chế độ xem mà không yêu cầu mã truy cập dữ liệu của bạn thay đổi.

Tôi đã từng là một người đàn ông to lớn, nhưng tôi bắt đầu nghiêng về LINQ như một sự thay thế tốt hơn nói chung. Nếu có một số khu vực mà sprocs rõ ràng tốt hơn, thì có lẽ tôi vẫn sẽ viết một sproc nhưng truy cập nó bằng LINQ. :)

Tôi nói chung là một người đề xuất đưa mọi thứ vào các thủ tục được lưu trữ, vì tất cả các lý do DBA đã gây ra trong nhiều năm. Trong trường hợp của Linq, đúng là sẽ không có sự khác biệt về hiệu năng với các truy vấn CRUD đơn giản.

Nhưng hãy ghi nhớ một số điều khi đưa ra quyết định này: sử dụng bất kỳ ORM nào kết hợp chặt chẽ với mô hình dữ liệu của bạn. Một DBA không có quyền tự do thực hiện các thay đổi đối với mô hình dữ liệu mà không buộc bạn phải thay đổi mã được biên dịch. Với các thủ tục được lưu trữ, bạn có thể ẩn các loại thay đổi này ở một mức độ nào đó, vì danh sách tham số và (các) kết quả được trả về từ một thủ tục thể hiện hợp đồng của nó và các bộ phận bên trong có thể được thay đổi, miễn là hợp đồng đó vẫn được đáp ứng .

Và ngoài ra, nếu Linq được sử dụng cho các truy vấn phức tạp hơn, điều chỉnh cơ sở dữ liệu trở thành một nhiệm vụ khó khăn hơn nhiều. Khi một thủ tục được lưu trữ đang chạy chậm, DBA hoàn toàn có thể tập trung vào mã một cách riêng lẻ và có rất nhiều tùy chọn, vì vậy hợp đồng đó vẫn được thỏa mãn khi hoàn thành.

Tôi đã thấy nhiều, rất nhiều trường hợp các vấn đề nghiêm trọng trong một ứng dụng được giải quyết bằng các thay đổi đối với lược đồ và mã trong các thủ tục được lưu trữ mà không có bất kỳ thay đổi nào đối với mã được biên dịch, triển khai.

Có lẽ một cách tiếp cận hybird sẽ tốt với Linq? Linq, tất nhiên, có thể được sử dụng để gọi các thủ tục được lưu trữ.

Linq đến Sql.

Máy chủ Sql sẽ lưu trữ các kế hoạch truy vấn, do đó không có hiệu suất tăng cho các sprocs.

Mặt khác, các câu lệnh linq của bạn sẽ là một phần logic và được kiểm tra với ứng dụng của bạn. Sprocs luôn cách nhau một chút và khó bảo trì và kiểm tra hơn.

Nếu tôi đang làm việc trên một ứng dụng mới từ đầu, tôi sẽ chỉ sử dụng Linq, không có sprocs.

Để lấy dữ liệu cơ bản, tôi sẽ đi Linq mà không do dự.

Kể từ khi chuyển đến Linq, tôi đã tìm thấy những lợi thế sau:

1. Gỡ lỗi DAL của tôi chưa bao giờ dễ dàng hơn thế.
2. Biên dịch an toàn thời gian khi thay đổi lược đồ của bạn là vô giá.
3. Triển khai dễ dàng hơn vì mọi thứ được biên dịch thành DLL. Không còn quản lý các kịch bản triển khai.
4. Vì Linq có thể hỗ trợ truy vấn mọi thứ thực hiện giao diện IQueryable, nên bạn sẽ có thể sử dụng cùng một cú pháp để truy vấn XML, Đối tượng và bất kỳ nguồn dữ liệu nào khác mà không phải học một cú pháp mới

LINQ sẽ làm mờ bộ đệm thủ tục

Nếu một ứng dụng đang sử dụng LINQ to SQL và các truy vấn liên quan đến việc sử dụng các chuỗi có độ dài thay đổi cao, bộ đệm thủ tục SQL Server sẽ trở nên đầy ắp với một phiên bản truy vấn cho mỗi độ dài chuỗi có thể. Ví dụ: hãy xem xét các truy vấn rất đơn giản sau đây được tạo đối với bảng Person.AddressTypes trong cơ sở dữ liệu AdventureWorks2008:

var p = 
    from n in x.AddressTypes 
    where n.Name == "Billing" 
    select n;

var p = 
    from n in x.AddressTypes 
    where n.Name == "Main Office" 
    select n;

Nếu cả hai truy vấn này đều được chạy, chúng ta sẽ thấy hai mục trong bộ đệm thủ tục SQL Server: Một mục được liên kết với NVARCHAR (7) và mục khác có NVARCHAR (11). Bây giờ hãy tưởng tượng nếu có hàng trăm hoặc hàng ngàn chuỗi đầu vào khác nhau, tất cả đều có độ dài khác nhau. Bộ đệm thủ tục sẽ trở nên đầy không cần thiết với tất cả các loại kế hoạch khác nhau cho cùng một truy vấn.

Xem thêm tại đây: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=363290

Tôi nghĩ rằng đối số LINQ chuyên nghiệp dường như đến từ những người không có lịch sử phát triển cơ sở dữ liệu (nói chung).

Đặc biệt, nếu sử dụng một sản phẩm như VS DB Pro hoặc Team Suite, chẳng hạn, nhiều đối số được đưa ra ở đây không áp dụng:

Khó bảo trì và kiểm tra hơn: VS cung cấp kiểm tra cú pháp đầy đủ, kiểm tra kiểu, kiểm tra tham chiếu và ràng buộc và hơn thế nữa. Nó cũng cung cấp khả năng kiểm tra đơn vị đầy đủ và các công cụ tái cấu trúc.

LINQ làm cho thử nghiệm đơn vị thực sự là không thể vì (trong suy nghĩ của tôi) nó thất bại trong thử nghiệm ACID.

Gỡ lỗi dễ dàng hơn trong LINQ: Tại sao? VS cho phép nhập đầy đủ từ mã được quản lý và gỡ lỗi SP thường xuyên.

Được biên dịch thành một DLL duy nhất thay vì các tập lệnh triển khai: Một lần nữa, VS đến giải cứu nơi nó có thể xây dựng và triển khai cơ sở dữ liệu đầy đủ hoặc thực hiện các thay đổi gia tăng an toàn dữ liệu.

Đừng học TSQL với LINQ: Không, bạn không học, nhưng bạn phải học LINQ - lợi ích ở đâu?

Tôi thực sự không thấy điều này là một lợi ích. Về mặt lý thuyết, việc có thể thay đổi điều gì đó có vẻ tốt, nhưng chỉ vì những thay đổi hoàn thành hợp đồng không có nghĩa là nó sẽ trả lại kết quả chính xác. Để có thể xác định kết quả chính xác là gì bạn cần bối cảnh và bạn có được bối cảnh đó từ mã gọi.

Ừm, các ứng dụng ghép lỏng lẻo là mục tiêu cuối cùng của tất cả các lập trình viên giỏi vì chúng thực sự làm tăng tính linh hoạt. Có thể thay đổi mọi thứ trong sự cô lập là điều tuyệt vời, và chính các bài kiểm tra đơn vị của bạn sẽ đảm bảo nó vẫn trả về kết quả phù hợp.

Trước khi tất cả các bạn buồn, tôi nghĩ LINQ có vị trí của nó và có một tương lai lớn. Nhưng đối với các ứng dụng phức tạp, nhiều dữ liệu, tôi không nghĩ rằng nó đã sẵn sàng để thay thế các thủ tục được lưu trữ. Đây là một quan điểm mà tôi đã lặp lại bởi một MVP tại TechEd năm nay (chúng sẽ vẫn không tên).

EDIT: Mặt thủ tục lưu trữ LINQ to SQL của mọi thứ là thứ tôi vẫn cần đọc thêm - tùy thuộc vào những gì tôi tìm thấy, tôi có thể thay đổi diatribe ở trên;)

LINQ là mới và có vị trí của nó. LINQ không được phát minh để thay thế thủ tục lưu trữ.

Ở đây tôi sẽ tập trung vào một số huyền thoại về hiệu suất & TIÊU DÙNG, chỉ với "LINQ to SQL", tất nhiên tôi có thể hoàn toàn sai ;-)

(1) Mọi người nói rằng thống kê LINQ có thể "lưu trữ" trong máy chủ SQL, vì vậy nó không làm giảm hiệu suất. Một phần đúng. "LINQ to SQL" thực sự là thời gian chạy dịch cú pháp LINQ sang trạng thái TSQL. Vì vậy, từ góc độ hiệu năng, một câu lệnh SQL ADO.NET được mã hóa cứng không có sự khác biệt so với LINQ.

(2) Cho một ví dụ, UI dịch vụ khách hàng có chức năng "chuyển tài khoản". chính chức năng này có thể cập nhật 10 bảng DB và trả về một số thông báo trong một lần chụp. Với LINQ, bạn phải xây dựng một tập hợp các câu lệnh và gửi chúng dưới dạng một đợt đến máy chủ SQL. hiệu suất của lô LINQ-> TSQL được dịch này khó có thể khớp với thủ tục được lưu trữ. Lý do? bởi vì bạn có thể điều chỉnh đơn vị nhỏ nhất của câu lệnh trong thủ tục được lưu trữ bằng cách sử dụng công cụ lập kế hoạch thực thi và trình biên dịch SQL tích hợp, bạn không thể thực hiện điều này trong LINQ.

Vấn đề là, khi nói bảng DB đơn và tập dữ liệu nhỏ CRUD, LINQ nhanh như SP. Nhưng đối với logic phức tạp hơn nhiều, thủ tục lưu trữ có thể điều chỉnh hiệu năng cao hơn.

(3) "LINQ to SQL" dễ dàng tạo ra những người mới để giới thiệu hiệu suất. Bất kỳ anh chàng TSQL cao cấp nào cũng có thể cho bạn biết khi nào không nên sử dụng CURSOR (Về cơ bản, bạn không nên sử dụng CURSOR trong TSQL trong hầu hết các trường hợp). Với LINQ và vòng lặp "foreach" quyến rũ với truy vấn, thật dễ dàng cho một người mới viết mã như vậy:

foreach(Customer c in query)
{
  c.Country = "Wonder Land";
}
ctx.SubmitChanges();

Bạn có thể thấy mã tốt dễ dàng này là rất hấp dẫn. Nhưng dưới mui xe, .NET runtime chỉ dịch phần này sang một đợt cập nhật. Nếu chỉ có 500 dòng thì đây là lô TSQL 500 dòng; Nếu có hàng triệu dòng, đây là một hit. Tất nhiên, người dùng có kinh nghiệm sẽ không sử dụng cách này để thực hiện công việc này, nhưng vấn đề là, thật dễ dàng để rơi vào cách này.

Mã tốt nhất là không có mã và với các thủ tục được lưu trữ, bạn phải viết ít nhất một số mã trong cơ sở dữ liệu và mã trong ứng dụng để gọi nó, trong khi với LINQ to SQL hoặc LINQ to Entities, bạn không phải viết thêm mã ngoài bất kỳ truy vấn LINQ nào khác ngoài việc khởi tạo một đối tượng bối cảnh.

LINQ chắc chắn có chỗ đứng trong cơ sở dữ liệu dành riêng cho ứng dụng và trong các doanh nghiệp nhỏ.

Nhưng trong một doanh nghiệp lớn, nơi các cơ sở dữ liệu trung tâm đóng vai trò là trung tâm dữ liệu chung cho nhiều ứng dụng, chúng ta cần sự trừu tượng hóa. Chúng ta cần quản lý tập trung bảo mật và hiển thị lịch sử truy cập. Chúng ta cần có khả năng phân tích tác động: nếu tôi thực hiện một thay đổi nhỏ cho mô hình dữ liệu để phục vụ nhu cầu kinh doanh mới, những truy vấn nào cần được thay đổi và những ứng dụng nào cần được kiểm tra lại? Lượt xem và thủ tục lưu trữ cho tôi điều đó. Nếu LINQ có thể làm tất cả những điều đó và làm cho các lập trình viên của chúng tôi làm việc hiệu quả hơn, tôi sẽ hoan nghênh điều đó - có ai có kinh nghiệm sử dụng nó trong loại môi trường này không?

Một DBA không có quyền tự do thực hiện các thay đổi đối với mô hình dữ liệu mà không buộc bạn phải thay đổi mã được biên dịch. Với các thủ tục được lưu trữ, bạn có thể ẩn các loại thay đổi này ở một mức độ nào đó, vì danh sách tham số và (các) kết quả được trả về từ một thủ tục thể hiện hợp đồng của nó và các bộ phận bên trong có thể được thay đổi, miễn là hợp đồng đó vẫn được đáp ứng .

Tôi thực sự không thấy điều này là một lợi ích. Về mặt lý thuyết, việc có thể thay đổi điều gì đó có vẻ tốt, nhưng chỉ vì những thay đổi hoàn thành hợp đồng không có nghĩa là nó sẽ trả lại kết quả chính xác. Để có thể xác định kết quả chính xác là gì bạn cần bối cảnh và bạn có được bối cảnh đó từ mã gọi.

IMHO, RAD = LINQ, RUP = Procs được lưu trữ. Tôi đã làm việc cho một công ty Fortune 500 lớn trong nhiều năm, ở nhiều cấp độ bao gồm cả quản lý, và thẳng thắn, tôi sẽ không bao giờ thuê các nhà phát triển RUP để phát triển RAD. Họ im lặng đến nỗi họ rất hạn chế kiến ​​thức về những việc cần làm ở các cấp độ khác của quy trình. Với một môi trường im lặng, sẽ rất hợp lý khi trao quyền kiểm soát dữ liệu cho các DBA thông qua các điểm vào rất cụ thể, bởi vì những người khác thực sự không biết cách tốt nhất để thực hiện quản lý dữ liệu.

Nhưng các doanh nghiệp lớn di chuyển rất chậm trong lĩnh vực phát triển, và điều này là vô cùng tốn kém. Có những lúc bạn cần di chuyển nhanh hơn để tiết kiệm cả thời gian và tiền bạc, và LINQ cung cấp điều đó và nhiều hơn nữa trong các trò chơi.

Đôi khi tôi nghĩ rằng các DBA thiên vị chống lại LINQ vì họ cảm thấy điều đó đe dọa đến an ninh công việc của họ. Nhưng đó là bản chất của con thú, quý bà và quý ông.

Tôi nghĩ rằng bạn cần phải đi với procs cho bất cứ điều gì thực sự.

A) Viết tất cả logic của bạn trong linq có nghĩa là cơ sở dữ liệu của bạn ít hữu ích hơn vì chỉ ứng dụng của bạn mới có thể sử dụng nó.

B) Tôi không tin rằng mô hình đối tượng tốt hơn mô hình quan hệ.

C) Kiểm tra và phát triển một thủ tục được lưu trữ trong SQL nhanh hơn rất nhiều so với chu trình chỉnh sửa biên dịch trong bất kỳ môi trường Visual Studio nào. Bạn chỉ cần chỉnh sửa, F5 và nhấn select và bạn đã sẵn sàng tham gia cuộc đua.

D) Dễ dàng quản lý và triển khai các thủ tục được lưu trữ hơn các cụm .. bạn chỉ cần đặt tệp lên máy chủ và nhấn F5 ...

E) Linq to sql vẫn viết mã crappy vào những lúc bạn không mong đợi nó.

Thành thật mà nói, tôi nghĩ rằng điều tối thượng sẽ là MS tăng cường t-sql để nó có thể thực hiện phép chiếu tham gia một cách rõ ràng theo cách linq làm. t-sql nên biết nếu bạn muốn làm order.lineitems.part chẳng hạn.

LINQ không cấm sử dụng các thủ tục được lưu trữ. Tôi đã sử dụng chế độ hỗn hợp với LINQ-SQL và LINQ-archiveproc . Cá nhân, tôi rất vui vì tôi không phải viết các procs được lưu trữ .... pwet-tu.

Ngoài ra, có vấn đề rollback 2.0 có thể. Tin tôi đi, nó đã xảy ra với tôi một vài lần rồi nên tôi chắc chắn nó đã xảy ra với người khác.

Tôi cũng đồng ý rằng sự trừu tượng là tốt nhất. Cùng với thực tế, mục đích ban đầu của ORM là làm cho RDBMS khớp với các khái niệm OO. Tuy nhiên, nếu mọi thứ hoạt động tốt trước LINQ bằng cách phải đi chệch một chút so với các khái niệm OO thì hãy bắt vít. Khái niệm và thực tế không phải lúc nào cũng phù hợp với nhau. Không có chỗ cho những người nhiệt tình trong CNTT.

Tôi giả sử bạn có nghĩa là Linq To Sql

Đối với bất kỳ lệnh CRUD nào, thật dễ dàng để xác định hiệu suất của một thủ tục được lưu trữ so với bất kỳ công nghệ nào. Trong trường hợp này, bất kỳ sự khác biệt giữa hai sẽ không đáng kể. Hãy thử định hình cho một đối tượng trường 5 (loại đơn giản) trên 100.000 truy vấn chọn để tìm hiểu xem có sự khác biệt thực sự không.

Mặt khác, công cụ thỏa thuận thực sự sẽ là câu hỏi liệu bạn có cảm thấy thoải mái khi đưa logic kinh doanh của mình vào cơ sở dữ liệu của mình hay không, đó là một lập luận chống lại các thủ tục được lưu trữ.

Theo các bậc thầy, tôi định nghĩa LINQ là xe máy và SP là ô tô. Nếu bạn muốn đi một chuyến đi ngắn và chỉ có những hành khách nhỏ (trong trường hợp này là 2), hãy duyên dáng với LINQ. Nhưng nếu bạn muốn đi một hành trình và có một ban nhạc lớn, tôi nghĩ bạn nên chọn SP.

Kết luận, việc lựa chọn giữa xe máy hoặc xe hơi phụ thuộc vào tuyến đường (kinh doanh), thời gian (thời gian) và hành khách (dữ liệu) của bạn.

Hy vọng nó sẽ giúp, tôi có thể sai. : D

Tất cả những câu trả lời này nghiêng về LINQ chủ yếu nói về EASE of PHÁT TRIỂN liên quan ít nhiều đến chất lượng mã hóa kém hoặc sự lười biếng trong mã hóa. Tôi chỉ như vậy thôi.

Một số ưu điểm hoặc Linq, tôi đọc ở đây là, dễ kiểm tra, dễ gỡ lỗi, v.v., nhưng đây không phải là nơi kết nối với đầu ra cuối cùng hoặc người dùng cuối. Điều này luôn luôn gây ra rắc rối cho người dùng cuối về hiệu suất. Điểm gì tải nhiều thứ trong bộ nhớ và sau đó áp dụng các bộ lọc trong khi sử dụng LINQ?

Một lần nữa TypeSafe, lưu ý rằng "chúng tôi cẩn thận để tránh lỗi đánh máy sai", một lần nữa chất lượng kém mà chúng tôi đang cố gắng cải thiện bằng cách sử dụng linq. Ngay cả trong trường hợp đó, nếu bất cứ điều gì trong cơ sở dữ liệu thay đổi, ví dụ kích thước của cột String, thì linq cần được biên dịch lại và sẽ không an toàn nếu không có điều đó .. Tôi đã thử.

Mặc dù, chúng tôi thấy là tốt, ngọt ngào, thú vị, v.v. khi làm việc với LINQ, nó có nhược điểm là làm cho nhà phát triển lười biếng :) và nó đã được chứng minh 1000 lần rằng nó tệ (có thể tệ nhất) về hiệu năng so với Stored Procs.

Đừng lười biếng nữa. Tôi đang cố gắng hết sức. :)

Đối với các hoạt động CRUD đơn giản với một điểm truy cập dữ liệu duy nhất, tôi sẽ nói hãy truy cập LINQ nếu bạn cảm thấy thoải mái với cú pháp. Đối với logic phức tạp hơn, tôi nghĩ rằng sprocs có hiệu suất hiệu quả hơn nếu bạn giỏi T-SQL và các hoạt động nâng cao hơn của nó. Bạn cũng có sự trợ giúp từ Tune Advisor, SQL Server Profiler, gỡ lỗi các truy vấn của bạn từ SSMS, v.v.

Thủ tục lưu trữ giúp kiểm tra dễ dàng hơn và bạn có thể thay đổi truy vấn mà không cần chạm vào mã ứng dụng. Ngoài ra với linq, nhận dữ liệu không có nghĩa là dữ liệu phù hợp. Và kiểm tra tính chính xác của dữ liệu có nghĩa là chạy ứng dụng nhưng với quy trình được lưu trữ, thật dễ dàng để kiểm tra mà không cần chạm vào ứng dụng.

Kết quả có thể được tóm tắt là

LinqToSql cho các trang web nhỏ và nguyên mẫu. Nó thực sự tiết kiệm thời gian cho Prototyping.

Sps: Phổ thông. Tôi có thể tinh chỉnh các truy vấn của mình và luôn kiểm tra ActualExecutPlan / Ước tínhExecutPlan.

Create PROCEDURE userInfoProcedure
    -- Add the parameters for the stored procedure here
    @FirstName varchar,
    @LastName varchar
AS
BEGIN

    SET NOCOUNT ON;

    -- Insert statements for procedure here
    SELECT FirstName  , LastName,Age from UserInfo where FirstName=@FirstName
    and LastName=@FirstName
END
GO

http://www.totaldotnet.com/Article/ShowArticle121_StoreProcBasic.aspx

Cả LINQ và SQL đều có vị trí của chúng. Cả hai đều có nhược điểm và lợi thế của họ.

Đôi khi để lấy dữ liệu phức tạp, bạn có thể cần các procs được lưu trữ. Và đôi khi bạn có thể muốn người khác sử dụng Proc được lưu trữ của bạn trong Sql Server Management Studio.

Linq to Entities rất tốt cho việc phát triển CRUD nhanh.

Chắc chắn bạn có thể xây dựng một ứng dụng chỉ bằng cách này hay cách khác. Hoặc bạn có thể trộn nó lên. Tất cả xuất phát từ yêu cầu của bạn. Nhưng các procs lưu trữ SQL sẽ không biến mất bất cứ lúc nào sớm.