Khi nào sử dụng RDLC trên báo cáo RDL?


117

Tôi đã nghiên cứu SSRS 2005/2008 trong những tuần qua và đã tạo một số báo cáo phía máy chủ. Đối với một số ứng dụng, một đồng nghiệp đã gợi ý rằng tôi nên xem xét RDLC cho tình huống cụ thể đó. Bây giờ tôi đang cố gắng tìm hiểu sự khác biệt chính giữa RDL và RDLC.

Tìm kiếm thông tin này mang lại thông tin phân mảnh tốt nhất. Tôi đã học được rằng:

  • Các báo cáo RDLC không lưu trữ thông tin về cách lấy dữ liệu.
  • Các báo cáo RDLC có thể được thực thi trực tiếp bởi điều khiển ReportViewer.

Nhưng tôi vẫn chưa hiểu đầy đủ về mối quan hệ giữa tệp RDLC và các hệ thống liên quan khác (Máy chủ báo cáo, cơ sở dữ liệu nguồn, máy khách).

Để hiểu rõ về các tệp RDLC, tôi muốn biết cách sử dụng của chúng khác với tệp RDL và trong tình huống nào người ta sẽ chọn RDLC thay vì RDL. Liên kết đến các nguồn tài nguyên cũng được hoan nghênh.

Cập nhật:

Một chủ đề trên diễn đàn ASP.NET thảo luận về vấn đề tương tự. Từ đó, tôi đã hiểu rõ hơn về vấn đề này.

Một tính năng của RDLC là nó có thể chạy hoàn toàn phía máy khách trong điều khiển ReportViewer.

  • Điều này loại bỏ nhu cầu về phiên bản Dịch vụ báo cáo và thậm chí loại bỏ nhu cầu đối với bất kỳ kết nối cơ sở dữ liệu nào, nhưng:
  • Nó bổ sung thêm yêu cầu rằng dữ liệu cần thiết trong báo cáo phải được cung cấp theo cách thủ công.

Cho dù đây là một lợi thế hay một bất lợi phụ thuộc vào ứng dụng cụ thể.

Trong ứng dụng của tôi, bản sao của Dịch vụ báo cáo vẫn có sẵn và dữ liệu cần thiết cho báo cáo có thể dễ dàng được lấy từ cơ sở dữ liệu. Còn lý do nào để tôi xem xét RDLC, hay tôi chỉ nên gắn bó với RDL?

Câu trả lời:


84

Từ kinh nghiệm của tôi, có vài điều cần suy nghĩ về cả hai điều:

I. Báo cáo RDL nói chung là báo cáo HOSTED. Điều này có nghĩa là bạn cần triển khai SSRS Server. Chúng là một phần mở rộng được tích hợp sẵn của Visual Studio từ SQL Server cho ngôn ngữ báo cáo. Khi cài đặt SSRS, bạn sẽ có một tiện ích bổ sung có tên là 'Business Intelligence Development Studio', tiện ích này sẽ dễ làm việc với các báo cáo hơn nhiều so với khi không có nó.

R eport

Định nghĩa D

L angauge

Lợi ích của báo cáo RDL:

  1. Bạn có thể lưu trữ các báo cáo trong một môi trường có các dịch vụ chạy cho bạn trên đó.
  2. Bạn có thể định cấu hình bảo mật trên một mục hoặc mức kế thừa để xử lý bảo mật dưới dạng một khái niệm độc lập
  3. Bạn có thể định cấu hình dịch vụ để gửi email (miễn là bạn có máy chủ SMTP mà bạn có quyền truy cập) và lưu tệp theo lịch trình
  4. Bạn có một cơ sở dữ liệu thường được gọi là 'Máy chủ báo cáo', bạn có thể truy vấn thông tin về các báo cáo sau khi được xuất bản.
  5. Bạn vẫn có thể truy cập các báo cáo này thông qua 'ReportViewer' trong ứng dụng khách được viết bằng ASP.NET, WPF (với winform control bleh!) Hoặc Winforms trong .NET bằng cách sử dụng 'ProcessingMode.Remote'.
  6. Bạn có thể đặt các thông số mà người dùng có thể nhìn thấy và sử dụng để linh hoạt hơn.
  7. Bạn có thể định cấu hình các phần của báo cáo được sử dụng cho các chuỗi kết nối làm 'Nguồn dữ liệu' cũng như truy vấn sql, xml hoặc các tập dữ liệu khác dưới dạng 'Tập dữ liệu'. Những phần này và những phần khác có thể được lưu trữ và định cấu hình để lưu trữ dữ liệu vào bộ nhớ cache một cách thường xuyên.
  8. Bạn có thể viết các lớp proxy .NET của các dịch vụ http: // / ReportServer / ReportingService2010 hoặc / ReportExecution2005. Sau đó, bạn có thể tạo các phương thức RIÊNG của mình trong .NET để gửi email, lưu hoặc thao tác dữ liệu SSRS từ dịch vụ trực tiếp của Máy chủ lưu trữ báo cáo SSRS bằng mã. Lập trình Xuất báo cáo SSRS từ điểm chia sẻ bằng ReportService2010.asmx

Nhược điểm:

  1. SSRS là loại chìa khóa thắng lợi so với những thứ khác về việc khởi động nhanh. Hầu hết mọi người đều bối rối bởi chính sách bảo mật và việc thiết kế các báo cáo như một 'phần bổ sung' cho VS. SQL 2005 = VS BIDS 2005, SQL 2008 = VS BIDS 2008, SQL 2012 = VS BIDS 2010 (LOL).
  2. Tiếp tục trên 1, chính sách cho cài đặt bảo mật IMHO là quá mức đơn giản. Có bảo mật máy chủ, bảo mật cơ sở dữ liệu và vai trò, hai cài đặt bảo mật trên trang được lưu trữ cho dịch vụ. Hầu hết mọi người chỉ thiết lập quản trị viên chứ không thể đăng nhập và tự hỏi tại sao những người dùng khác không thể. Hầu hết các khiếu nại hoặc câu hỏi phổ biến về SSRS đều liên quan đến việc nhận được thông tin từ kinh nghiệm của tôi.
  3. Bạn có thể sử dụng 'biểu thức' được cho là sẽ 'nâng cao' báo cáo của bạn. Thông thường, bạn làm nhiều hơn một vài và báo cáo của bạn sẽ thu thập thông tin về hiệu suất.
  4. Bạn có một số thứ bạn có thể làm và xuất. SSRS không di chuột qua báo cáo mà tôi biết nếu không có javascript hack.
  5. Tốc độ và hiệu suất có thể bị ảnh hưởng vì cấu hình SSRS ngu ngốc tái chế hệ thống và báo cáo đầu tiên có thể mất một lúc chỉ khi tải trang web. Bạn có thể giải quyết vấn đề này bằng cách thay đổi nó nhưng tôi nhận thấy rằng việc tạo ra một dịch vụ duy trì hoạt động để nó hoạt động tốt hơn.

II. Báo cáo RDLC là báo cáo CÓ CHỨA KHÁCH HÀNG KHÔNG ĐƯỢC LƯU TRỮ BẤT CỨ Ở ĐÂU. Thêm c trong tên có nghĩa là 'Khách hàng'. Nói chung, đây là một phần mở rộng của ngôn ngữ RDL chỉ được sử dụng trong các Ứng dụng Máy khách Visual Studio. Nó tồn tại trong Visual Studio khi bạn thêm một mục 'báo cáo'.

Lợi ích của báo cáo RDLC:

  1. Bạn có thể kết nối một dịch vụ wcf dễ dàng hơn nhiều với tập dữ liệu.
  2. Bạn có nhiều quyền kiểm soát hơn đối với tập dữ liệu và có thể sử dụng các lớp POCO chứa đầy các đối tượng khung Entity hoặc ADO.NET trực tiếp cũng như bản thân các bảng. Bạn có thể lấy dữ liệu để tối ưu hóa nó trước khi liên kết nó với báo cáo.
  3. Bạn có thể tùy chỉnh giao diện nhiều hơn với tiện ích mở rộng trực tiếp trong mã phía sau.

Nhược điểm:

  1. Bạn cần phải tự mình xử lý các tham số và trong khi bạn có thể triển khai các phương thức wrapper để giúp công việc của bạn hơi nhiều hơn mong đợi và đáng tiếc.
  2. Người dùng không thể XEM các tham số trong điều khiển 'Trình xem báo cáo' trừ khi điều khiển đó ở chế độ từ xa và truy cập báo cáo RLD. Vì vậy, bạn cần tạo các hộp văn bản, danh sách thả xuống, các nút radio bên ngoài điều khiển để chuyển tới nó. Một số người thích điều này được thêm vào kiểm soát, cá nhân tôi thì không.
  3. Bất cứ điều gì bạn muốn làm với việc phục vụ các báo cáo để phân phối, bạn cần phải tự xây dựng. Gửi email, đăng ký, lưu. Rất tiếc, bạn cần phải xây dựng điều đó trong .NET hoặc nếu không, hãy triển khai một proxy đã làm điều đó từ phía trên, bạn chỉ có thể sử dụng các báo cáo được lưu trữ.

Thành thật mà nói tôi thích cả hai cho các mục đích khác nhau. Nếu tôi muốn điều gì đó đưa ra cho các nhà phân tích mà họ sử dụng mọi lúc và chỉnh sửa đồ thị, biểu đồ, xem chi tiết và xuất sang Excel, tôi sử dụng RDL và chỉ cần trang web của SSRS thực hiện tất cả các công việc xử lý các bản phân phối email. Nếu tôi muốn một ứng dụng có phần báo cáo và tôi biết rằng ứng dụng đó là mô-đun riêng của nó với các quy tắc và quản trị, tôi sử dụng một RDLC và có các tham số nhỏ hơn và được điều khiển bởi các quyết định mà người dùng đưa ra trước khi chuyển đến phần báo cáo. khách hàng họ đang truy cập và trang web và sau đó họ thường chỉ chọn khung thời gian hoặc loại và không có gì hơn. Vì vậy, nói chung một báo cáo phức tạp tôi sẽ sử dụng RDL và đối với một số thứ đơn giản, tôi sẽ sử dụng RDLC IMHO.

Tôi hy vọng rằng sẽ giúp.


57

Q: Sự khác biệt giữa định dạng RDL và RDLC là gì?

Đ: Tệp RDL được tạo bởi phiên bản SQL Server 2005 của Trình thiết kế báo cáo. Các tệp RDLC được tạo bởi phiên bản Visual Studio 2008 của Trình thiết kế báo cáo.

Các định dạng RDL và RDLC có cùng một lược đồ XML. Tuy nhiên, trong tệp RDLC, một số giá trị (chẳng hạn như văn bản truy vấn) được phép để trống, có nghĩa là chúng chưa sẵn sàng ngay lập tức để được xuất bản lên Máy chủ Báo cáo. Các giá trị bị thiếu có thể được nhập bằng cách mở tệp RDLC sử dụng phiên bản SQL Server 2005 của Trình thiết kế báo cáo. (Trước tiên bạn phải đổi tên .rdlc thành .rdl.)

Tệp RDL hoàn toàn tương thích với thời gian chạy điều khiển ReportViewer. Tuy nhiên, tệp RDL không chứa một số thông tin mà thời gian thiết kế của điều khiển ReportViewer phụ thuộc vào để tự động tạo mã liên kết dữ liệu. Bằng cách liên kết dữ liệu theo cách thủ công, các tệp RDL có thể được sử dụng trong điều khiển ReportViewer. Mới! Xem thêm chương trình mẫu RDL Viewer.

Lưu ý rằng điều khiển ReportViewer không chứa bất kỳ logic nào để kết nối với cơ sở dữ liệu hoặc thực thi truy vấn. Bằng cách tách ra logic như vậy, ReportViewer đã được làm cho tương thích với tất cả các nguồn dữ liệu, bao gồm cả các nguồn dữ liệu không phải cơ sở dữ liệu. Tuy nhiên, điều này có nghĩa là khi điều khiển ReportViewer sử dụng tệp RDL, thì thông tin liên quan đến SQL trong tệp RDL sẽ bị điều khiển bỏ qua. Ứng dụng chủ có trách nhiệm kết nối với cơ sở dữ liệu, thực thi các truy vấn và cung cấp dữ liệu cho điều khiển ReportViewer dưới dạng ADO.NET DataTables.

http://www.gotreportviewer.com/


Tôi có thể Sử dụng các đối tượng tùy chỉnh ( List<T>của MyEntity) làm nguồn cho Báo cáo Từ xa ( RDL ), không phải RDLC không?
Kiquenet,

21

Tôi đã luôn nghĩ rằng sự khác biệt giữa RDL và RDLC là RDL được sử dụng cho SQL Server Reporting Services và RDLC được sử dụng trong Visual Studio cho báo cáo phía máy khách. Việc đặt và biên tập gần như giống hệt nhau. RDL là viết tắt của Report Defintion LanguageRDLC Report Definition Language Client-side .

Tôi hy vọng rằng sẽ giúp.


3
Tôi không thể chú ý đến phần 'phía máy khách', cho đến khi tôi nhận ra rằng với RDLC, có thể (thậm chí là bắt buộc) để cung cấp dữ liệu cho báo cáo theo cách thủ công mà không buộc phải kết nối với một số cơ sở dữ liệu.
Daan 07/07/09

16

Theo kinh nghiệm của tôi, nếu bạn cần hiệu suất cao (điều này hơi phụ thuộc vào thông số kỹ thuật khách hàng của bạn) trên các báo cáo lớn, hãy sử dụng rdlc. Ngoài ra, báo cáo rdlc cung cấp cho bạn toàn bộ quyền kiểm soát đối với dữ liệu của mình, bạn có thể tiết kiệm cho mình các chuyến đi cơ sở dữ liệu lãng phí, v.v. bằng cách sử dụng báo cáo phía máy khách. Trong dự án mà tôi hiện đang thực hiện, một báo cáo quan trọng cần khoảng 2 phút để hiển thị ở phía máy chủ và mất khá nhiều thời gian cho bất kỳ máy chủ báo cáo nào mà nó truy cập vào thời điểm đó. Chuyển nó sang hiển thị phía máy khách, chúng tôi thấy hiệu suất gần hơn nhiều với 20-40 giây mà máy chủ báo cáo không tải và băng thông được sử dụng ít hơn vì chỉ có bộ dữ liệu đang được tải xuống.

Số dặm của bạn có thể thay đổi và tôi nhận thấy sự phức tạp trong việc phát triển và bảo trì của rdlc, đặc biệt khi báo cáo của bạn được thiết kế dưới dạng báo cáo phía máy chủ.


Tôi nghĩ ở đây là tốt nhất, liên quan đến hiệu suất, đặt báo cáo RDL vào một máy chủ từ xa có Dịch vụ báo cáo đang chạy. Bạn không cần cập nhật từng máy trạm khách hàng của mình (bạn chỉ cần cập nhật một báo cáo duy nhất trong một trang web). Có một sự cố rò rỉ bộ nhớ trong phiên bản 2005 và một số lỗi nhỏ dường như có thể tránh được khi sử dụng các dịch vụ báo cáo.
Junior Mayhé

1
Tôi không tích cực những gì bạn đang cố gắng nói. Chúng tôi đã tìm thấy hiệu suất tốt nhất bằng cách sử dụng báo cáo phía khách hàng. RDL trên một máy chủ từ xa là một điểm nghẽn lớn đối với chúng tôi.
Marr75

2
Điều này phụ thuộc rất nhiều vào a) khả năng xử lý tương đối của máy chủ báo cáo và b) liệu các điều khiển trình xem báo cáo của bạn có được định cấu hình để xử lý cục bộ hay từ xa hay không. Bằng cách sử dụng các điều khiển của trình xem báo cáo trong chế độ xử lý cục bộ, bạn đang chuyển công việc xử lý báo cáo sang máy khách, điều này có thể có lợi trong trường hợp máy chủ báo cáo không có khả năng xử lý khối lượng công việc (ví dụ: nếu có nhiều máy khách). Tuy nhiên, một máy chủ báo cáo có thông số kỹ thuật hợp lý sẽ có thể xử lý hầu hết các khối lượng công việc báo cáo. Các điểm nghẽn khác có thể là thiết kế báo cáo / truy vấn và nguồn dữ liệu.
Nathan Griffiths

1
Tại thời điểm tôi trả lời câu hỏi này, các báo cáo phía máy chủ không xử lý tốt người dùng đồng thời, về cơ bản chỉ xử lý một yêu cầu tại một thời điểm (tôi sẽ rất ngạc nhiên nếu điều này đã được cải tiến). Hơn nữa, trong môi trường của chúng tôi (và nhiều môi trường khác mà tôi phải giả định), việc hiển thị báo cáo là một chi tiết rất nhỏ so với công việc được thực hiện bởi máy chủ cơ sở dữ liệu. Báo cáo phía khách hàng đã cho chúng tôi nhiều quyền kiểm soát hơn đối với các khía cạnh đồng thời của ứng dụng. Tuy nhiên, nó làm tăng thêm độ phức tạp cho hệ thống. Vì vậy, đó là một quyết định kỹ thuật được thực hiện.
Marr75, 13/12/12

@ marr75 - Quy mô máy chủ và máy khách khác nhau. Với phía máy chủ, bạn có nhiều khả năng gặp phải bức tường gạch hơn khi bạn thuê 25 nhân viên và tất cả họ đều tấn công máy chủ cùng một lúc. Với phía khách hàng, tất cả 25 người đều có máy tính riêng để đỡ gánh nặng, vì vậy bạn có thể không đụng phải bất kỳ bức tường gạch nào - khi công ty của bạn phát triển, giải pháp phía máy chủ yêu cầu nhiều người trông trẻ hơn. Điều đó nói rằng, bạn có thể tối ưu hóa máy chủ nhiều hơn và điều đó chỉ cần được thực hiện tại một nơi - tôi đang nghĩ đến việc xây dựng các chỉ mục phù hợp - liên quan đến DBA của bạn. Sở thích của tôi là sử dụng phía máy khách, nhưng tối ưu hóa cả hai để có hiệu suất tối đa!
MicroservicesOnDDD

11

Một số điểm này đã được giải quyết ở trên, nhưng đây là 2 xu của tôi cho môi trường VS2008.

RDL (Báo cáo từ xa): Trải nghiệm phát triển tốt hơn nhiều, linh hoạt hơn nếu bạn cần sử dụng một số tính năng nâng cao như lập lịch, báo cáo đặc biệt, v.v.

RDLC (Báo cáo cục bộ): Kiểm soát tốt hơn dữ liệu trước khi gửi đến báo cáo (dễ dàng hơn để xác nhận hoặc thao tác dữ liệu trước khi gửi đến báo cáo). Triển khai dễ dàng hơn nhiều, không cần phiên bản Dịch vụ báo cáo.

Một cảnh báo LỚN với các báo cáo cục bộ là rò rỉ bộ nhớ đã biết có thể ảnh hưởng nghiêm trọng đến hiệu suất nếu khách hàng của bạn đang chạy nhiều báo cáo lớn. Điều này phải được giải quyết bằng phiên bản VS2010 mới của trình xem báo cáo.

Trong trường hợp của tôi, vì chúng tôi có sẵn phiên bản Dịch vụ báo cáo, tôi phát triển các báo cáo mới dưới dạng RDL và sau đó chuyển đổi chúng thành báo cáo cục bộ (điều này thật dễ dàng) và triển khai chúng dưới dạng báo cáo cục bộ.


7

Nếu bạn có sẵn cơ sở hạ tầng dịch vụ báo cáo cho mình, hãy sử dụng nó. Bạn sẽ thấy phát triển RDL dễ chịu hơn một chút. Bạn có thể xem trước báo cáo, dễ dàng thiết lập các thông số, v.v.


7

Trong khi tôi hiện đang nghiêng về RDL vì nó có vẻ linh hoạt hơn và dễ quản lý hơn, RDLC có một lợi thế ở chỗ nó dường như đơn giản hóa việc cấp phép của bạn. Vì RDLC không cần phiên bản Dịch vụ Báo cáo, bạn sẽ không cần Giấy phép Dịch vụ Báo cáo để sử dụng nó.

Tôi không chắc liệu điều này có còn áp dụng với các phiên bản SQL Server mới hơn hay không, nhưng tại một thời điểm nếu bạn chọn đặt các phiên bản Dịch vụ báo cáo và Cơ sở dữ liệu SQL Server trên hai máy riêng biệt, bạn bắt buộc phải có hai giấy phép SQL Server riêng biệt:
http://social.msdn.microsoft.com/forums/en-US/sqlgetstarted/thread/82dd5acd-9427-4f64-aea6-511f09aac406/

Bạn có thể Bing cho các blog và bài đăng tương tự khác liên quan đến việc cấp phép Dịch vụ Báo cáo.


3
Cấp phép SQL Server vẫn yêu cầu bạn phải có giấy phép cho mọi máy đã cài đặt BẤT KỲ thành phần nào của SQL Server. Do đó, việc triển khai quy mô lớn trong đó cơ sở dữ liệu máy chủ báo cáo nằm trên một máy chủ khác với dịch vụ máy chủ báo cáo yêu cầu giấy phép riêng cho từng máy chủ.
Nathan Griffiths

2

Đối với VS2008, tôi tin rằng RDL cung cấp cho bạn các tính năng chỉnh sửa tốt hơn RDLC. Ví dụ: tôi có thể thay đổi Chữ in đậm trên một lượng văn bản đã chọn trong hộp văn bản với RDL, trong khi trong RDLC thì không thể.

RDL: abcd efgh ijklmnop

RDLC: abcd efgh ijklmnop abcd efgh ijklmnop (là những lựa chọn duy nhất của bạn)

Điều này là do RDLC đang sử dụng không gian tên / định dạng cũ hơn từ năm 2005, trong khi RDL đang sử dụng 2008. Tuy nhiên, điều này sẽ thay đổi với VS2010


4
Điều này không phải do sự khác biệt giữa rdl và rdlc, đây là sự khác biệt giữa các dịch vụ báo cáo máy chủ sql 2005 và 2008. Trình xem báo cáo phân phối lại các phân phối lại của máy chủ sql, hỗ trợ báo cáo phía máy khách, độ trễ này là lý do cho sự khác biệt bạn đang mô tả.
marr75

1
vì số lượng lớn lỗi, tôi đang chuyển từ 2005 (RDLC) sang Dịch vụ báo cáo 2008 (RDL)
Junior Mayhé

1

Nếu chúng ta có số lượng báo cáo ít phức tạp hơn và được sử dụng bởi các trang web asp.net. Tốt hơn là nên sử dụng rdlc, lý do là chúng ta có thể tránh bảo trì các báo cáo trên cá thể RS. nhưng chúng ta phải tìm nạp dữ liệu từ DB theo cách thủ công và liên kết nó với rdlc.

Nhược điểm: thiết kế rdlc trong studio trực quan hơi khó so với thiết kế SSrs.

Pro: Bảo trì dễ dàng. trong khi xuất báo cáo từ trang của chúng tôi, đã quan sát thấy mức tăng hiệu suất so với báo cáo phía máy chủ.


-3

nếu bạn muốn sử dụng báo cáo trong asp.net thì hãy sử dụng .rdl nếu bạn muốn sử dụng / xem trong trình tạo báo cáo / máy chủ báo cáo thì hãy sử dụng .rdlc chỉ bằng cách chuyển đổi định dạng theo cách thủ công.


Điều này dường như đã hoán đổi RDL và RDLC về nơi chúng chạy - và ngay cả khi nó không chạy, điều này sẽ không thêm bất cứ điều gì hữu ích cho hàng chục câu trả lời hiện có.
underscore_d

rdlc là phần mở rộng để báo cáo cục bộ, bạn có thể sử dụng trong aspnet, winforms hoặc wpf. msdn.microsoft.com/es-es/library/ms252104.aspx . Bạn không thể sử dụng file .rdlc trong chế độ xử lý từ xa
dgzornoza
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.