Когда использовать RDLC вместо отчетов RDL?

117

В последние недели я изучал SSRS 2005/2008 и создал несколько отчетов на стороне сервера. Для какого-то приложения коллега предложил мне изучить RDLC для этой конкретной ситуации. Теперь я пытаюсь понять основное различие между RDL и RDLC.

Поиск этой информации дает в лучшем случае фрагментированную информацию. Я узнал, что:

  • Отчеты RDLC не хранят информацию о том, как получить данные.
  • Отчеты RDLC могут выполняться непосредственно элементом управления ReportViewer.

Но я до сих пор не совсем понимаю взаимосвязь между файлом RDLC и другими связанными системами (сервер отчетов, исходная база данных, клиент).

Чтобы получить хорошее представление о файлах RDLC, я хотел бы знать, чем их использование отличается от файлов RDL и в какой ситуации можно выбрать RDLC вместо RDL. Также приветствуются ссылки на ресурсы.

Обновить:

Нить на форумах ASP.NET обсуждает этот же вопрос. Из этого я получил лучшее понимание этого вопроса.

Особенностью RDLC является то, что он может быть запущен полностью на стороне клиента в элементе управления ReportViewer.

  • Это устраняет необходимость в экземпляре служб Reporting Services и даже устраняет необходимость в любом подключении к базе данных, но:
  • Он добавляет требование о том, что данные, необходимые для отчета, должны быть предоставлены вручную.

Является ли это преимуществом или недостатком, зависит от конкретного приложения.

В моем приложении экземпляр служб Reporting Services в любом случае доступен, и необходимые данные для отчетов можно легко извлечь из базы данных. Есть ли у меня какие-либо причины для рассмотрения RDLC, или я должен просто придерживаться RDL?

Даан
источник

Ответы:

84

По моему опыту, есть несколько вещей, о которых стоит подумать об обоих:

I. Отчеты RDL, как правило, являются HOSTED-отчетами. Это означает, что вам необходимо внедрить SSRS Server. Они являются встроенным расширением Visual Studio от SQL Server для языка отчетов. Когда вы устанавливаете SSRS, у вас должно быть надстройка под названием «Business Intelligence Development Studio», с которой гораздо проще работать с отчетами, чем без нее.

R тЧЕТ

D efinition

L angauge

Преимущества отчетов RDL:

  1. Вы можете разместить отчеты в среде, в которой для вас работают службы.
  2. Вы можете настроить безопасность на уровне элемента или наследования, чтобы обеспечить безопасность как отдельную концепцию.
  3. Вы можете настроить службу для рассылки электронных писем (при условии, что у вас есть SMTP-сервер, к которому у вас есть доступ) и сохранения файлов по расписанию.
  4. У вас есть база данных, которая обычно называется ReportServer, и вы можете запрашивать информацию об опубликованных отчетах.
  5. Вы можете получить доступ к этим отчетам через ReportViewer в клиентском приложении, написанном на ASP.NET, WPF (с помощью элемента управления winform bleh!) Или Winforms в .NET, используя ProcessingMode.Remote.
  6. Вы можете установить параметры, которые пользователь может видеть и использовать для большей гибкости.
  7. Вы можете настроить части отчета, которые будут использоваться для строк подключения как «Источники данных», а также для запроса sql, xml или других наборов данных как «Набор данных». Эти и другие части можно хранить и настраивать для регулярного кэширования данных.
  8. Вы можете написать прокси-классы .NET для служб http: // / ReportServer / ReportingService2010 или / ReportExecution2005. Затем вы можете создать свои СОБСТВЕННЫЕ методы в .NET для отправки по электронной почте, сохранения или управления данными SSRS из службы непосредственно на сервере, на котором размещены отчеты SSRS в коде. Программный экспорт отчета SSRS из sharepoint с помощью ReportService2010.asmx

Недостатки:

  1. SSRS - это немного странно по сравнению с другими вещами при быстром запуске. Большинство людей смущает политика безопасности и создание отчетов как «надстройки» к VS. SQL 2005 = VS BIDS 2005, SQL 2008 = VS BIDS 2008, SQL 2012 = VS BIDS 2010 (LOL).
  2. Продолжая на 1, политика для настроек безопасности IMHO идиотски сложна. На странице, размещенной для службы, есть безопасность сервера, безопасность базы данных и роли, два параметра безопасности. Большинство людей настраивают только администратора, которого не могут войти, и задаются вопросом, почему другие пользователи не могут. Наиболее частые жалобы или вопросы по SSRS связаны с моим опытом.
  3. Вы можете использовать «выражения», которые со временем «улучшат» ваш отчет. Часто вы делаете больше, чем несколько, и ваш отчет сканируется по производительности.
  4. У вас есть определенное количество вещей, которые вы можете делать и во что экспортировать. В SSRS нет наведения указателя мыши на отчеты, о которых я знаю без взлома javascript.
  5. Скорость и производительность могут пострадать, так как глупая конфигурация SSRS перезапускает систему, а первый отчет может занять некоторое время, иногда просто загружая сайт. Вы можете обойти это, изменив его, но я обнаружил, что служба поддержки активности работает лучше.

II. Отчеты RDLC - это ОТЧЕТЫ, ПОДДЕРЖИВАЕМЫЕ КЛИЕНТОМ, которые НИКОГДА НЕ РАЗМЕЩАЮТСЯ. Дополнительный c в названии означает «Клиент». Обычно это расширение языка RDL, предназначенное для использования только в клиентских приложениях Visual Studio. Он существует в Visual Studio, когда вы добавляете элемент «отчетность».

Преимущества отчетов RDLC:

  1. Вы можете гораздо проще подключить службу wcf к набору данных.
  2. У вас больше контроля над набором данных, и вы можете использовать классы POCO, заполненные объектами Entity framework или ADO.NET напрямую, а также сами таблицы. Вы можете обезопасить данные для оптимизации перед их привязкой к отчету.
  3. Вы можете настроить внешний вид с помощью надстроек прямо в коде.

Недостатки:

  1. Вам нужно обрабатывать параметры самостоятельно, и хотя вы можете реализовать методы-оболочки, чтобы облегчить беготню, это немного больше, чем ожидалось, и прискорбно.
  2. Пользователь не может ВИДЕТЬ параметры в элементе управления ReportViewer, если он не находится в удаленном режиме и не обращается к отчету RLD. Таким образом, вам нужно сделать текстовые поля, выпадающие списки, переключатели самостоятельно за пределами элемента управления, чтобы перейти к нему. Кому-то нравится этот дополнительный контроль, мне лично нет.
  3. Все, что вы хотите сделать с обслуживанием отчетов для распространения, вам нужно создать самостоятельно. Электронная почта, подписки, сохранение. Извините, вам нужно создать это в .NET или реализовать прокси, который уже делает это сверху, вы можете просто использовать размещенные отчеты.

Честно говоря, мне нравятся оба для разных целей. Если я хочу передать аналитикам что-то, что они используют все время и настраивают для графиков, диаграмм, детализации и экспорта в Excel, я использую RDL, а сайт SSRS выполняет всю работу по обработке рассылки электронной почты. Если мне нужно приложение, в котором есть раздел отчета, и я знаю, что приложение - это собственный модуль с правилами и управлением, я использую RDLC, с меньшими параметрами и руководствуюсь решениями, которые пользователь принял перед тем, как перейти к части отчета. клиент, на котором они находятся, и сайт, а затем они обычно просто выбирают временные рамки или тип и ничего более. Так что обычно для сложных отчетов я бы использовал RDL, а для чего-то простого я бы использовал RDLC IMHO.

Надеюсь, это поможет.

djangojazz
источник
57

В: В чем разница между форматами RDL и RDLC?

О: Файлы RDL создаются конструктором отчетов версии SQL Server 2005. Файлы RDLC создаются версией конструктора отчетов Visual Studio 2008.

Форматы RDL и RDLC имеют одинаковую схему XML. Однако в файлах RDLC некоторые значения (например, текст запроса) могут быть пустыми, что означает, что они не готовы к немедленной публикации на сервере отчетов. Отсутствующие значения можно ввести, открыв файл RDLC с помощью версии конструктора отчетов SQL Server 2005. (Сначала вам нужно переименовать .rdlc в .rdl.)

Файлы RDL полностью совместимы со средой выполнения элемента управления ReportViewer. Однако файлы RDL не содержат некоторой информации, от которой зависит время разработки элемента управления ReportViewer для автоматического создания кода привязки данных. Путем привязки данных вручную файлы RDL можно использовать в элементе управления ReportViewer. Новый! См. Также пример программы RDL Viewer.

Обратите внимание, что элемент управления ReportViewer не содержит никакой логики для подключения к базам данных или выполнения запросов. Разделив такую ​​логику, ReportViewer стал совместимым со всеми источниками данных, включая источники данных, не относящиеся к базе данных. Однако это означает, что когда файл RDL используется элементом управления ReportViewer, связанная с SQL информация в файле RDL просто игнорируется элементом управления. Основное приложение отвечает за подключение к базам данных, выполнение запросов и предоставление данных элементу управления ReportViewer в форме таблиц данных ADO.NET.

http://www.gotreportviewer.com/

Мэтью Лок
источник
Могу ли я использовать настраиваемые объекты List<T>в MyEntityкачестве источника для удаленных отчетов ( RDL ), а не RDLC ?
Kiquenet
21

Я всегда думал, что разница между RDL и RDLC заключается в том, что RDL используются для служб отчетов SQL Server, а RDLC используются в Visual Studio для отчетов на стороне клиента. Реализация и редактор практически идентичны. RDL означает Report Defintion Languageи RDLC Report Definition Language Client-side .

Надеюсь, это поможет.

Комар Майк
источник
3
Я не мог осмыслить «клиентскую» часть, пока не понял, что с помощью RDLC можно (даже необходимо) вручную предоставить данные в отчет, без принудительного подключения к какой-либо базе данных.
Daan
16

По моему опыту, если вам нужна высокая производительность (это немного зависит от характеристик вашего клиента) для больших отчетов, используйте rdlc. Кроме того, отчеты rdlc дают вам очень полный контроль над вашими данными, вы можете сэкономить впустую поездки к базе данных и т.д., используя отчеты на стороне клиента. В проекте, над которым я сейчас работаю, критический отчет требует около 2 минут для рендеринга на стороне сервера и в значительной степени забирает любой сервер отчетов, на который он попадает за это время. Переключив его на рендеринг на стороне клиента, мы видим, что производительность намного ближе к 20-40 секундам без нагрузки на сервер отчетов и с меньшей полосой пропускания, поскольку загружаются только наборы данных.

Ваш опыт может отличаться, и я считаю, что rdlc добавляет сложность разработки и обслуживания, особенно когда ваш отчет был разработан как отчет на стороне сервера.

marr75
источник
Я думаю, что с точки зрения производительности лучше всего разместить отчеты RDL на удаленном сервере с запущенными службами Reporting Services. Вам не нужно обновлять каждую рабочую станцию ​​ваших клиентов (вам просто нужно обновить один отчет только на одном сайте). В версии 2005 года есть утечка памяти и несколько мелких ошибок, которых, кажется, можно избежать при использовании служб отчетов.
Junior Mayhé
1
Я не уверен в том, что вы пытаетесь сказать. Мы уже нашли лучшую производительность с помощью отчетов на стороне клиента. RDL на удаленном сервере были для нас большим узким местом.
marr75
2
Это во многом зависит от а) относительной способности сервера отчетов к обработке и б) от того, настроены ли элементы управления средства просмотра отчетов для локальной или удаленной обработки. Используя элементы управления средства просмотра отчетов в режиме локальной обработки, вы передаете работу по обработке отчетов клиенту, что может быть полезно в ситуации, когда сервер отчетов не имеет возможности обрабатывать рабочую нагрузку (например, если клиентов много). Однако сервер отчетов с достаточно хорошей спецификацией должен быть в состоянии обрабатывать большинство рабочих нагрузок отчетов. Другими узкими местами могут быть дизайн отчетов / запросов и источники данных.
Натан Гриффитс
1
На тот момент, когда я ответил на это, отчеты на стороне сервера не очень хорошо обрабатывали одновременных пользователей, в основном просто обрабатывая один запрос за раз (я был бы очень удивлен, если бы это было улучшено вообще). Более того, в нашей среде (и во многих других, я должен предположить) отрисовка отчета - очень незначительная деталь по сравнению с работой, выполняемой сервером базы данных. Отчеты на стороне клиента дали нам гораздо больше контроля над аспектами параллелизма в приложении. Однако это добавляет системе дополнительную сложность. Итак, это инженерное решение.
marr75
@ marr75 - Сервер против клиента масштабируется по-разному. Что касается серверной части, вы с большей вероятностью столкнетесь с кирпичной стеной, если наймете 25 сотрудников, и все они сразу попадут на сервер. Что касается клиентской стороны, все 25 получают свой собственный компьютер, чтобы нести бремя, поэтому вы можете вообще не удариться о кирпичную стену - по мере роста вашей компании решение на стороне сервера требует больше присмотра за детьми. Тем не менее, вы можете оптимизировать сервер больше, и это нужно делать только в одном месте - я думаю о создании правильных индексов - с привлечением вашего администратора базы данных. Я предпочитаю использовать клиентскую сторону, но оптимизировать обе для максимальной производительности!
MicroservicesOnDDD
11

Некоторые из этих вопросов были рассмотрены выше, но вот мои 2 цента для среды VS2008.

RDL (удаленные отчеты): гораздо лучший опыт разработки, большая гибкость, если вам нужно использовать некоторые расширенные функции, такие как планирование, специальные отчеты и т. Д.

RDLC (локальные отчеты): лучший контроль над данными перед их отправкой в ​​отчет (проще проверять или манипулировать данными перед их отправкой в ​​отчет). Намного более простое развертывание, нет необходимости в экземпляре служб Reporting Services.

Одна ОГРОМНАЯ оговорка в отношении локальных отчетов - это известная утечка памяти, которая может серьезно повлиять на производительность, если ваши клиенты будут запускать множество больших отчетов. Предполагается, что эта проблема будет устранена с помощью новой версии средства просмотра отчетов для VS2010.

В моем случае, поскольку у нас есть доступный экземпляр служб Reporting Services, я разрабатываю новые отчеты как RDL, а затем конвертирую их в локальные отчеты (что легко) и развертываю как локальные отчеты.

Харрисон
источник
7

Если у вас есть доступная инфраструктура служб отчетов, используйте ее. Вы обнаружите, что разработка RDL немного приятнее. Вы можете предварительно просмотреть отчет, легко настроить параметры и т. Д.

Кевин Фишер
источник
7

Пока я сейчас склоняюсь к RDL, потому что он кажется более гибким и легким в управлении, у RDLC есть преимущество в том, что он, кажется, упрощает ваше лицензирование. Поскольку RDLC не требуется экземпляр служб Reporting Services, для его использования вам не потребуется лицензия служб Reporting Services.

Я не уверен, применимо ли это по-прежнему к более новым версиям SQL Server, но в какой-то момент, если вы решили разместить экземпляры SQL Server Database и Reporting Services на двух разных машинах, вам потребовалось бы иметь две отдельные лицензии SQL Server:
http://social.msdn.microsoft.com/forums/en-US/sqlgetstarted/thread/82dd5acd-9427-4f64-aea6-511f09aac406/

Вы можете Bing для других подобных блогов и сообщений, касающихся лицензирования служб Reporting Services.

Шон Ири
источник
3
Лицензирование SQL Server по-прежнему требует наличия лицензии для каждой машины, на которой установлен ЛЮБОЙ компонент SQL Server. Поэтому для масштабного развертывания, когда базы данных сервера отчетов находятся на другом сервере, чем служба сервера отчетов, требуется отдельная лицензия для каждого сервера.
Натан Гриффитс
2

Я считаю, что для VS2008 RDL предоставляет лучшие возможности редактирования, чем RDLC. Например, я могу изменить полужирный шрифт на выбранном количестве текста в текстовом поле с помощью RDL, в то время как в RDLC это невозможно.

RDL: abcd efgh ijklmnop

RDLC: abcd efgh ijklmnop abcd efgh ijklmnop (это ваши единственные варианты)

Это связано с тем, что RDLC использует более раннее пространство имен / форматирование с 2005 года, в то время как RDL использует 2008. Однако это изменится с VS2010

avgbody
источник
4
Это не из-за разницы между rdl и rdlc, это разница между службами отчетов сервера sql 2005 и 2008. Распространяемые компоненты средства просмотра отчетов, которые отстают от разработки сервера sql, поддерживают отчеты на стороне клиента, это отставание является причиной разницы вы описываете.
marr75
1
из-за большого количества ошибок я перехожу с 2005 (RDLC) на 2008 Reporting Services (RDL)
Джуниор Майе
1

Если у нас будет меньше отчетов, которые менее сложны и используются веб-страницами asp.net. Лучше использовать rdlc, потому что мы можем избежать поддержки отчетов на экземпляре RS. но нам нужно вручную получить данные из БД и привязать их к rdlc.

Минусы: проектирование rdlc в visual studio не так сложно по сравнению с дизайнером SSrs.

Плюсы: простое обслуживание. при экспорте отчета со страницы мы заметил, что производительность выше по сравнению с отчетами на стороне сервера.

WingsOfFire
источник
-3

если вы хотите использовать отчет в asp.net, используйте .rdl, если вы хотите использовать / просмотреть в построителе отчетов / сервере отчетов, тогда используйте .rdlc, просто конвертируя формат вручную, он работает

mahendramaid
источник
Похоже, что RDL и RDLC поменялись местами с точки зрения того, где они запускаются - и даже если бы этого не произошло, это не добавило бы ничего полезного к десяткам существующих ответов.
underscore_d
rdlc - это расширение для локальных отчетов, которое можно использовать в aspnet, winforms или wpf. msdn.microsoft.com/es-es/library/ms252104.aspx . Вы не можете использовать файлы .rdlc в режиме удаленной обработки
dgzornoza 05