У меня есть быстро растущий набор отчетов Telerik в моем веб-проекте. Моя стратегия предоставления данных состоит в том, что каждый отчет имеет текстовый файл, содержащий SQL-запрос. Я обрабатываю сложные критерии фильтра, такие как long 'x находится в (y, z, a, b, c ....)', или '((x = 1) и (x < y))', повторяется сто раз , выполнив текстовые замены в запросе текстового файла, прежде чем использовать его для получения DataTable для отчета.Сообщить о метаданных в сборнике отчетов [Telerik]
Все отчеты представляют собой классы, которые производятся от Telerik.Reporting.Report
, которые имеют ограниченные свойства, которые служат в качестве метаданных отчета, таких как название бизнеса отчета, по сравнению с программным именем отчета. Нет полей для таких атрибутов, как категория отчета, имя файла запроса SQL для отчета, возможная альтернативная страница просмотра отчета, поднабор общих параметров фильтра для отключения отчета и т. Д.
Я считаю, что первые решения для кандидатов здесь непривлекательны, а именно: создавая и поддерживая хранилище настроек отчета, либо в файле, либо в файле web.config, либо в таблице базы данных. Этот магазин отделен от фактических отчетов, и работа в них или в магазине требует частых и раздражающих обменов контекстом.
Моя более предпочтительная идея - использовать нечто похожее на схему метаданных Dynamic Data, где атрибут класса сущности присваивает другому классу метаданные для объекта. Я мог бы также расширить Telerik.Reporting.Report
, добавив, может быть, словарь для атрибутов, которые я хочу прикрепить к отчетам, и получить от него все мои отчеты.
Любая критика в отношении моего текущего мышления или предложений по другим вариантам будет оценена по достоинству.