По моему опыту, есть несколько вещей, о которых стоит подумать об обоих:
I. Отчеты RDL, как правило, являются HOSTED-отчетами. Это означает, что вам необходимо внедрить SSRS Server. Они являются встроенным расширением Visual Studio от SQL Server для языка отчетов. Когда вы устанавливаете SSRS, у вас должно быть надстройка под названием «Business Intelligence Development Studio», с которой гораздо проще работать с отчетами, чем без нее.
R тЧЕТ
D efinition
L angauge
Преимущества отчетов RDL:
- Вы можете разместить отчеты в среде, в которой для вас работают службы.
- Вы можете настроить безопасность на уровне элемента или наследования, чтобы обеспечить безопасность как отдельную концепцию.
- Вы можете настроить службу для рассылки электронных писем (при условии, что у вас есть SMTP-сервер, к которому у вас есть доступ) и сохранения файлов по расписанию.
- У вас есть база данных, которая обычно называется ReportServer, и вы можете запрашивать информацию об опубликованных отчетах.
- Вы можете получить доступ к этим отчетам через ReportViewer в клиентском приложении, написанном на ASP.NET, WPF (с помощью элемента управления winform bleh!) Или Winforms в .NET, используя ProcessingMode.Remote.
- Вы можете установить параметры, которые пользователь может видеть и использовать для большей гибкости.
- Вы можете настроить части отчета, которые будут использоваться для строк подключения как «Источники данных», а также для запроса sql, xml или других наборов данных как «Набор данных». Эти и другие части можно хранить и настраивать для регулярного кэширования данных.
- Вы можете написать прокси-классы .NET для служб http: // / ReportServer / ReportingService2010 или / ReportExecution2005. Затем вы можете создать свои СОБСТВЕННЫЕ методы в .NET для отправки по электронной почте, сохранения или управления данными SSRS из службы непосредственно на сервере, на котором размещены отчеты SSRS в коде.
Программный экспорт отчета SSRS из sharepoint с помощью ReportService2010.asmx
Недостатки:
- SSRS - это немного странно по сравнению с другими вещами при быстром запуске. Большинство людей смущает политика безопасности и создание отчетов как «надстройки» к VS. SQL 2005 = VS BIDS 2005, SQL 2008 = VS BIDS 2008, SQL 2012 = VS BIDS 2010 (LOL).
- Продолжая на 1, политика для настроек безопасности IMHO идиотски сложна. На странице, размещенной для службы, есть безопасность сервера, безопасность базы данных и роли, два параметра безопасности. Большинство людей настраивают только администратора, которого не могут войти, и задаются вопросом, почему другие пользователи не могут. Наиболее частые жалобы или вопросы по SSRS связаны с моим опытом.
- Вы можете использовать «выражения», которые со временем «улучшат» ваш отчет. Часто вы делаете больше, чем несколько, и ваш отчет сканируется по производительности.
- У вас есть определенное количество вещей, которые вы можете делать и во что экспортировать. В SSRS нет наведения указателя мыши на отчеты, о которых я знаю без взлома javascript.
- Скорость и производительность могут пострадать, так как глупая конфигурация SSRS перезапускает систему, а первый отчет может занять некоторое время, иногда просто загружая сайт. Вы можете обойти это, изменив его, но я обнаружил, что служба поддержки активности работает лучше.
II. Отчеты RDLC - это ОТЧЕТЫ, ПОДДЕРЖИВАЕМЫЕ КЛИЕНТОМ, которые НИКОГДА НЕ РАЗМЕЩАЮТСЯ. Дополнительный c в названии означает «Клиент». Обычно это расширение языка RDL, предназначенное для использования только в клиентских приложениях Visual Studio. Он существует в Visual Studio, когда вы добавляете элемент «отчетность».
Преимущества отчетов RDLC:
- Вы можете гораздо проще подключить службу wcf к набору данных.
- У вас больше контроля над набором данных, и вы можете использовать классы POCO, заполненные объектами Entity framework или ADO.NET напрямую, а также сами таблицы. Вы можете обезопасить данные для оптимизации перед их привязкой к отчету.
- Вы можете настроить внешний вид с помощью надстроек прямо в коде.
Недостатки:
- Вам нужно обрабатывать параметры самостоятельно, и хотя вы можете реализовать методы-оболочки, чтобы облегчить беготню, это немного больше, чем ожидалось, и прискорбно.
- Пользователь не может ВИДЕТЬ параметры в элементе управления ReportViewer, если он не находится в удаленном режиме и не обращается к отчету RLD. Таким образом, вам нужно сделать текстовые поля, выпадающие списки, переключатели самостоятельно за пределами элемента управления, чтобы перейти к нему. Кому-то нравится этот дополнительный контроль, мне лично нет.
- Все, что вы хотите сделать с обслуживанием отчетов для распространения, вам нужно создать самостоятельно. Электронная почта, подписки, сохранение. Извините, вам нужно создать это в .NET или реализовать прокси, который уже делает это сверху, вы можете просто использовать размещенные отчеты.
Честно говоря, мне нравятся оба для разных целей. Если я хочу передать аналитикам что-то, что они используют все время и настраивают для графиков, диаграмм, детализации и экспорта в Excel, я использую RDL, а сайт SSRS выполняет всю работу по обработке рассылки электронной почты. Если мне нужно приложение, в котором есть раздел отчета, и я знаю, что приложение - это собственный модуль с правилами и управлением, я использую RDLC, с меньшими параметрами и руководствуюсь решениями, которые пользователь принял перед тем, как перейти к части отчета. клиент, на котором они находятся, и сайт, а затем они обычно просто выбирают временные рамки или тип и ничего более. Так что обычно для сложных отчетов я бы использовал RDL, а для чего-то простого я бы использовал RDLC IMHO.
Надеюсь, это поможет.
List<T>
вMyEntity
качестве источника для удаленных отчетов ( RDL ), а не RDLC ?