W ostatnich tygodniach studiowałem SSRS 2005/2008 i utworzyłem kilka raportów po stronie serwera. W przypadku niektórych aplikacji kolega zasugerował, żebym zajrzał do RDLC w tej konkretnej sytuacji. Próbuję teraz zrozumieć główną różnicę między RDL i RDLC.

Wyszukiwanie tych informacji daje w najlepszym przypadku fragmentaryczne informacje. Dowiedziałem się, że:

• Raporty RDLC nie przechowują informacji o tym, jak uzyskać dane.
• Raporty RDLC mogą być wykonywane bezpośrednio przez kontrolkę ReportViewer.

Ale nadal nie rozumiem w pełni relacji między plikiem RDLC a innymi powiązanymi systemami (serwerem raportowania, źródłową bazą danych, klientem).

Aby dobrze zrozumieć pliki RDLC, chciałbym wiedzieć, czym ich użycie różni się od plików RDL i w jakiej sytuacji należy wybrać RDLC zamiast RDL. Mile widziane są również linki do zasobów.

Aktualizacja:

Wątek na forum ASP.NET omawia ten sam problem. Dzięki temu lepiej zrozumiałem ten problem.

Cechą RDLC jest to, że można go uruchomić całkowicie po stronie klienta w kontrolce ReportViewer.

• Eliminuje to potrzebę wystąpienia usług Reporting Services, a nawet eliminuje potrzebę jakiegokolwiek połączenia z bazą danych, ale:
• Dodaje wymóg, aby dane, które są potrzebne w raporcie, były dostarczane ręcznie.

To, czy jest to zaleta czy wada, zależy od konkretnego zastosowania.

W mojej aplikacji i tak jest dostępne wystąpienie usług Reporting Services, a wymagane dane do raportów można łatwo pobrać z bazy danych. Czy jest jakiś powód, dla którego powinienem rozważyć RDLC, czy po prostu powinienem trzymać się RDL?

Z mojego doświadczenia wynika, że ​​jest kilka rzeczy do przemyślenia obu rzeczy:

I. Raporty RDL są generalnie raportami HOSTED. Oznacza to, że musisz zaimplementować serwer SSRS. Stanowią one wbudowane rozszerzenie programu Visual Studio z SQL Server dla języka raportowania. Po zainstalowaniu SSRS powinieneś mieć dodatek o nazwie „Business Intelligence Development Studio”, który jest znacznie łatwiejszy w pracy z raportami niż bez niego.

R eport

D EFINICJA

L Angauge

Korzyści z raportów RDL:

1. Raporty można hostować w środowisku, w którym działają usługi.
2. Możesz skonfigurować zabezpieczenia dla elementu lub poziomu dziedziczenia, aby obsługiwać zabezpieczenia jako koncepcję autonomiczną
3. Możesz skonfigurować usługę do wysyłania wiadomości e-mail (pod warunkiem, że masz serwer SMTP, do którego masz dostęp) i zapisywania plików zgodnie z harmonogramem
4. Masz bazę danych ogólnie nazywaną „ReportServer”, w której możesz wyszukiwać informacje o raportach po ich opublikowaniu.
5. Dostęp do tych raportów można uzyskać nadal za pomocą „ReportViewer” w aplikacji klienckiej napisanej w ASP.NET, WPF (z kontrolką winform bleh!) Lub Winforms w .NET przy użyciu „ProcessingMode.Remote”.
6. Możesz ustawić parametry, które użytkownik może zobaczyć i których może używać, aby uzyskać większą elastyczność.
7. Możesz skonfigurować części raportu, które będą używane dla parametrów połączenia jako „Źródła danych”, a kwerendę sql, XML lub inne zestawy danych jako „Zestaw danych”. Te i inne części mogą być przechowywane i konfigurowane w celu regularnego buforowania danych.
8. Możesz napisać klasy proxy .NET usług http: // / ReportServer / ReportingService2010 lub / ReportExecution2005. Następnie możesz utworzyć własne metody w .NET do wysyłania e-maili, zapisywania lub manipulowania danymi SSRS z usługi bezpośrednio z serwera obsługującego raporty SSRS w kodzie. Programowo eksportuj raport SSRS z programu SharePoint przy użyciu ReportService2010.asmx

Wady:

1. SSRS jest swego rodzaju kluczem do sukcesu w porównaniu do innych rzeczy w szybkim uruchamianiu. Większość ludzi jest zdezorientowanych polityką bezpieczeństwa i projektowaniem raportów jako „dodatku” do VS. SQL 2005 = VS BIDS 2005, SQL 2008 = VS BIDS 2008, SQL 2012 = VS BIDS 2010 (LOL).
2. Kontynuując 1, zasady dotyczące ustawień bezpieczeństwa IMHO są idiotycznie skomplikowane. Istnieją zabezpieczenia serwera, zabezpieczenia bazy danych i role, dwa ustawienia zabezpieczeń na stronie hostowanej dla usługi. Większość ludzi tylko konfiguruje administratora, który nie może wejść i zastanawia się, dlaczego inni użytkownicy nie mogą. Najczęstsze skargi lub pytania dotyczące SSRS są związane z uzyskaniem się na podstawie mojego doświadczenia.
3. Możesz użyć „wyrażeń”, które rzekomo „poprawią” Twój raport. Często robisz więcej niż kilka i raport przechodzi do indeksowania wydajności.
4. Masz określoną liczbę rzeczy, które możesz robić i do których możesz eksportować. SSRS nie ma najeżdżania na raportowanie, o którym wiem, bez włamania do javascript.
5. Szybkość i wydajność mogą być hitem, ponieważ głupia konfiguracja SSRS odtwarza system, a pierwszy raport może chwilę potrwać, po prostu wczytując witrynę. Możesz to obejść, zmieniając to, ale odkryłem, że usługa utrzymywania przy życiu działa lepiej.

II. Raporty RDLC to raporty ZAWIERAJĄCE KLIENTA, które NIE SĄ NIGDZIE HOSTOWANE. Dodatkowe c w nazwie oznacza „Klient”. Ogólnie jest to rozszerzenie języka RDL przeznaczone do użytku tylko w aplikacjach klienckich programu Visual Studio. Istnieje w programie Visual Studio po dodaniu elementu „raportowania”.

Korzyści z raportów RDLC:

1. Możesz znacznie łatwiej podłączyć usługę wcf do zbioru danych.
2. Masz większą kontrolę nad zbiorem danych i możesz bezpośrednio używać klas POCO wypełnionych obiektami Entity Framework lub ADO.NET, a także samych tabel. Możesz małpować dane do optymalizacji przed powiązaniem ich z raportem.
3. Możesz bardziej dostosować wygląd za pomocą dodatków bezpośrednio w kodzie.

Wady:

1. Musisz samodzielnie obsługiwać parametry i chociaż możesz zaimplementować metody opakowujące, aby pomóc w pracy nóg, jest trochę więcej niż oczekiwano i niefortunnie.
2. Użytkownik nie może ZOBACZYĆ parametrów w kontrolce „ReportViewer”, chyba że jest w trybie zdalnym i uzyskuje dostęp do raportu RLD. Dlatego musisz samodzielnie tworzyć pola tekstowe, listy rozwijane, przyciski opcji poza kontrolą, aby do nich przejść. Niektórzy lubią to dodaną kontrolę, ja osobiście nie.
3. Wszystko, co chcesz zrobić z obsługą raportów do dystrybucji, musisz stworzyć samodzielnie. Wysyłanie e-maili, subskrypcje, oszczędzanie. Przepraszam, że musisz to zbudować w .NET lub zaimplementować proxy, które już to robi z góry, możesz po prostu korzystać z hostowanych raportów.

Szczerze mówiąc, lubię oba w różnych celach. Jeśli chcę coś przekazać analitykom, których używają cały czas i dostosowują do wykresów, wykresów, analiz i eksportu do Excela, używam RDL i po prostu zlecam stronie SSRS całą pracę związaną z obsługą dystrybucji e-maili. Jeśli chcę aplikację, która ma sekcję raportu i wiem, że aplikacja jest własnym modułem z regułami i zarządzaniem, używam RDLC, a parametry są mniejsze i kieruję się decyzjami podjętymi przez użytkownika przed przejściem do raportu. klienta, na którym są i na miejscu, a następnie zwykle wybierają przedział czasowy lub typ i nic więcej. Więc ogólnie złożony raport użyłbym RDL, a do czegoś prostego użyłbym RDLC IMHO.

Mam nadzieję że to pomogło.

P: Jaka jest różnica między formatami RDL i RDLC?

O: Pliki RDL są tworzone przez program Report Designer w wersji SQL Server 2005. Pliki RDLC są tworzone przez program Report Designer w wersji Visual Studio 2008.

Formaty RDL i RDLC mają ten sam schemat XML. Jednak w plikach RDLC niektóre wartości (takie jak tekst zapytania) mogą być puste, co oznacza, że ​​nie są one natychmiast gotowe do opublikowania na serwerze raportów. Brakujące wartości można wprowadzić, otwierając plik RDLC za pomocą narzędzia Report Designer w wersji SQL Server 2005. (Najpierw musisz zmienić nazwę .rdlc na .rdl).

Pliki RDL są w pełni zgodne ze środowiskiem wykonawczym formantu ReportViewer. Jednak pliki RDL nie zawierają pewnych informacji, od których zależy czas projektowania formantu ReportViewer w celu automatycznego generowania kodu powiązania danych. Dzięki ręcznemu wiązaniu danych pliki RDL mogą być używane w kontrolce ReportViewer. Nowy! Zobacz także przykładowy program RDL Viewer.

Należy zauważyć, że formant ReportViewer nie zawiera żadnej logiki do łączenia się z bazami danych lub wykonywania zapytań. Oddzielając taką logikę, ReportViewer został dostosowany do wszystkich źródeł danych, w tym źródeł danych innych niż bazy danych. Oznacza to jednak, że gdy plik RDL jest używany przez formant ReportViewer, informacje dotyczące języka SQL w pliku RDL są po prostu ignorowane przez formant. Za łączenie się z bazami danych, wykonywanie zapytań i dostarczanie danych do kontrolki ReportViewer w postaci ADO.NET DataTables odpowiada aplikacja hosta.

http://www.gotreportviewer.com/

Zawsze uważałem, że różnica między RDL i RDLC polega na tym, że RDL są używane dla usług SQL Server Reporting Services, a RDLC są używane w programie Visual Studio do raportowania po stronie klienta. Wdrożenie i edytor są prawie identyczne. RDL oznacza Report Defintion Languagei RDLC Report Definition Language Client-side .

Mam nadzieję że to pomogło.

Z mojego doświadczenia wynika, że ​​jeśli potrzebujesz wysokiej wydajności (zależy to nieco od specyfikacji klienta) w dużych raportach, skorzystaj z rdlc. Ponadto raporty rdlc zapewniają bardzo pełny zakres kontroli nad danymi, możesz zaoszczędzić sobie zmarnowanych podróży do bazy danych itp., Korzystając z raportów po stronie klienta. W projekcie, nad którym obecnie pracuję, raport krytyczny wymaga około 2 minut na renderowanie po stronie serwera i prawie całkowicie usuwa serwer raportowania, który trafi w tym czasie. Przełączając go na renderowanie po stronie klienta, widzimy wydajność znacznie bliższą 20-40 sekundom bez obciążenia serwera raportów i mniejszą przepustowością, ponieważ pobierane są tylko zestawy danych.

Twój przebieg może się różnić i uważam, że rdlc zwiększa złożoność rozwoju i konserwacji, zwłaszcza gdy raport został zaprojektowany jako raport po stronie serwera.

Niektóre z tych punktów zostały omówione powyżej, ale oto moje 2 centy dla środowiska VS2008.

RDL (zdalne raporty): znacznie lepsze środowisko programistyczne, większa elastyczność, jeśli potrzebujesz korzystać z niektórych zaawansowanych funkcji, takich jak planowanie, raportowanie ad-hoc itp.

RDLC (Raporty lokalne): Lepsza kontrola nad danymi przed wysłaniem ich do raportu (łatwiejsza weryfikacja danych lub manipulowanie nimi przed wysłaniem ich do raportu). Znacznie łatwiejsze wdrażanie, nie ma potrzeby korzystania z wystąpienia usług Reporting Services.

Ogromnym zastrzeżeniem dotyczącym raportów lokalnych jest znany wyciek pamięci, który może poważnie wpłynąć na wydajność, jeśli Twoi klienci będą uruchamiać wiele dużych raportów. Ma to zostać rozwiązane dzięki nowej wersji przeglądarki raportów VS2010.

W moim przypadku, ponieważ mamy dostępne wystąpienie usług Reporting Services, tworzę nowe raporty jako RDL, a następnie konwertuję je na raporty lokalne (co jest łatwe) i wdrażam jako raporty lokalne.

Jeśli masz dostępną infrastrukturę usług raportowania, użyj jej. Przekonasz się, że rozwój RDL będzie nieco przyjemniejszy. Możesz wyświetlić podgląd raportu, łatwo ustawić parametry itp.

Chociaż obecnie skłaniam się ku RDL, ponieważ wydaje się bardziej elastyczny i łatwiejszy w zarządzaniu, RDLC ma tę zaletę, że wydaje się upraszczać licencjonowanie. Ponieważ RDLC nie potrzebuje wystąpienia usług Reporting Services, do korzystania z niego nie jest potrzebna licencja na usługi Reporting Services.

Nie jestem pewien, czy to nadal ma zastosowanie w nowszych wersjach SQL Server, ale kiedyś, jeśli zdecydowałeś się umieścić wystąpienia SQL Server Database and Reporting Services na dwóch oddzielnych komputerach, wymagane były dwie oddzielne licencje SQL Server:
http://social.msdn.microsoft.com/forums/en-US/sqlgetstarted/thread/82dd5acd-9427-4f64-aea6-511f09aac406/

Możesz skorzystać z Bing dla innych podobnych blogów i postów dotyczących licencjonowania usług Reporting Services.

Uważam, że w przypadku VS2008 RDL zapewnia lepsze funkcje edycji niż RDLC. Na przykład mogę zmienić pogrubioną czcionkę na wybranej ilości tekstu w polu tekstowym za pomocą RDL, podczas gdy w RDLC nie jest to możliwe.

RDL: abcd efgh ijklmnop

RDLC: abcd efgh ijklmnop -or- abcd efgh ijklmnop (to jedyne opcje)

Dzieje się tak, ponieważ RDLC używa wcześniejszej przestrzeni nazw / formatowania z 2005 r., Podczas gdy RDL używa 2008. Jednak zmieni się to w VS2010

Jeśli mamy mniej raportów, które są mniej złożone i używane przez strony internetowe asp.net. Lepiej jest wybrać rdlc, ponieważ możemy uniknąć utrzymywania raportów na temat instancji RS. ale musimy ręcznie pobrać dane z DB i powiązać je z rdlc.

Wady: projektowanie rdlc w Visual Studio jest trochę trudne w porównaniu z projektantem SSrs.

Zaleta: konserwacja jest łatwa. podczas eksportowania raportu ze strony, zauważyłem wzrost wydajności w porównaniu z raportami po stronie serwera.

jeśli chcesz używać raportu w asp.net, użyj .rdl, jeśli chcesz używać / widoku w narzędziu do tworzenia raportów / serwerze raportów, użyj .rdlc, po prostu ręcznie konwertując format, działa