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

Question

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

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

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

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

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

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

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

Answer 1

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

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

Answer 2

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

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

Архитектурно мудрый, собираетесь ли вы запускать отчеты против живой базы данных или базы данных архива (или БД восстановления/восстановления)?

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