報告網站的架構

Question

在這個問題之前，我已經提到過這個項目，但重新設計的範圍稍微收緊了一點，也就是說我不能重新設計整個事情，所以我想提供一些關於如何在應用程序中構建現有的人工製品作爲改進設計的漸進步驟。

1. 該網站有兩個功能區域v.i.z.報告和維護。這是該網站的主要功能，而不是數據處理，只是簡報。該站點包含少量的維護頁面，這些頁面使用標準GridViews和FormViews來維護一小部分數據。這就是爲什麼我決定採用企業庫DAAB和普通香草數據集來支持豐富複雜的DAL。

2. 每個報告是使用動態SQL查詢的結果明確顯示HTML錶行的報告孤立的頁面。爲了不爲每個報表維護mySQL和MSSQL的一組查詢，我將把所有的數據訪問移動到存儲過程中，通過DAAB移除與數據庫引擎的耦合。

3. 我正在查看報告工具以從報告演示文稿中分離報告結構定義。我寧願不在類中定義報告結構，因爲telerik報告確實存在，但尚未查看其他報告工具。

4. 所有報表共享呈現在選擇從一個菜單，一旦用戶滿意他們的過濾器選擇其重定向到所選擇的報告的報告共同的過濾器頁面。是否有任何指導可用於這種非常常見的情況，我似乎不得不繼續改造？

我在尋找關於如何將此轉向更好的結構化產品的一般性建議，而無需實際重構整個項目。簡單的東西就像在子目錄報告頁面分離維護網頁等

我不希望給別人做我的工作，並會在適當的時候已經實現了我自己造成的許多改進，但我將不勝感激關於其他人如何處理這樣的項目的一般意見。

Answer 1

我打算與管理系統中去的元數據的報告，有一個簡單的目錄結構的頁每報表系統，使用的DevExpress ASPxGridView。這個網格不僅能夠滿足這個應用程序的報告需求。

我將以標準Web表單的形式實現維護和管理，併爲大多數報表提供共享過濾器表單，並根據報表元數據動態配置。將不會有運行時維護報告，因爲添加報告需要添加頁面。這是可以接受的，因爲維護是不經常的。

Answer 2

對於基於事實的數據庫報告演講中，我將調查的已經得到了所有的核心功能已經實施的工具，如BIRT一個（我相信，有一些.NET的替代品）。你可能認爲一張數據表對於一個聰明的人來說是足夠好解析的，但是下來的人會要求圖表和PDF。

維護/管理頁面可以是一個標準的網站 - 表單和後端，使用任何你喜歡的框架。

體系結構方面，您是否要針對活動數據庫或存檔數據庫（或故障轉移/複製數據庫）運行報告？

您是否正在生成聚合數據表（事實表）來生成報告或針對更復雜的主模式運行？