Архитектура для веб-сайта отчетности

Question

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

1. Сайт имеет две функциональные возможности, v.i.z. отчетность и сопровождение. Это основная функция сайта, не манипулирование данными, а просто презентация. Сайт включает в себя небольшое количество страниц обслуживания, которые используют стандартные GridViews и FormViews для обслуживания небольшой области данных. Вот почему я решил отказаться от богатого и сложного DAL в пользу DAAB Enterprise Library и простых ванильных наборов данных.

2. Каждый отчет представляет собой изолированную страницу, которая использует результаты динамического запроса SQL для явного отображения строк таблицы HTML для отчета. Чтобы не поддерживать один набор запросов для mySQL и MSSQL для каждого отчета, я перенесу весь доступ к данным к хранимым процедурам, удалив связь с любым механизмом БД через DAAB.

3. Я рассматриваю инструменты отчетности, чтобы отделить определение структуры отчета от представления отчета. Я бы предпочел не определять структуру отчета в классах, как это делает Telerik Reporting, но пока не рассматривал другие инструменты отчетности.

4. Все отчеты имеют общую страницу фильтра, которая отображается при выборе отчета из меню, которая перенаправляет на выбранный отчет, когда пользователь доволен выбором фильтра. Есть ли какое-либо руководство для этого очень распространенного сценария, который я, кажется, должен продолжать изобретать?

Я ищу общий совет о том, как продвинуть это к более структурированному продукту, фактически не реструктурируя весь проект. Простые вещи, такие как отделение страниц обслуживания от страниц отчета в подкаталогах и т. Д.

Я не ищу других, которые будут выполнять мою работу, и со временем внедрит много улучшений, сделанных мной, но я был бы признателен за общее мнение о том, как другие люди будут обращаться с таким проектом.

Answer 1

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

Страницы поддержки / администрирования могут быть стандартными веб-сайтами - формами и бэкэндом, используя любую удобную среду.

С точки зрения архитектуры, вы собираетесь запускать отчеты для действующей базы данных или архивной базы данных (или базы данных аварийного переключения / репликации)?

Генерируете ли вы таблицы агрегированных данных (таблицы фактов) для создания отчетов или работы с более сложной основной схемой?

Answer 2

Я собираюсь использовать систему управления метаданными для отчетов с простой структурой каталогов для системы страница-на-отчет с использованием DevExpress ASPxGridView. Эта сетка более чем способна удовлетворить потребности приложения в отчетности.

Я буду осуществлять обслуживание и администрирование в виде стандартных веб-форм с общей формой фильтра для большинства отчетов, динамически настраиваемой на основе метаданных отчета. Не будет никакого обслуживания отчетов во время выполнения, поскольку добавление отчета требует добавления страницы. Это приемлемо, так как обслуживание будет нечастым.