0

興味深い ASP ページを継承しました。このページには、さまざまなレポートがユーザーに表示されます。レポート タイプは、レポート ページが読み込まれる前に、左側のメニューからユーザーが選択します。レポート ページでは、レポート パラメータ (レポートの開始日と終了日など) をユーザーにクエリするために、比較的小さな画面要素のセットを使用しますが、約 20 の異なるレポートがあります。各レポートは、これらの要素のどれを表示するかを決定し、要求されたときにバックエンドでレポートを生成し、特定のレポートを表示するように変更された GridView でレポートを表示します。

実際、それはそれほど悪い構造ではありません。問題は、バッキング コード ファイルが約 4000 行のコードになっていることです。その多くは、switch または if then else ステートメントで、どのレポート タイプかを尋ねてから、特定のレポートの特殊なケースを処理します。

私がやりたいことは、各レポートを独自のクラス ファイルにプッシュし、ベース レポート ページ クラスから継承し、必要に応じて固有の変更を実装することです。次に、ページの読み込み中に適切なクラスを選択します (ページを読み込むメニュー選択でレポート タイプが選択されるため、これはわかっています)。

これを達成する方法について考えていますか？

4

1 に答える 1

1

部分クラスは簡単なルートです。コードを移動できますが、すべて同じクラス内にあるため、スコープには影響しません。

個別のクラスにリファクタリングすることはおそらく良い考えですが、コードが aspx ページに緊密に結合されているように思えます。これは同時に変更する必要があります。DataTableすべての新しいクラスがGridView にバインドされるa を返す場合でも。

私はおそらく次のような構造を試してみます：

aspx -- ユーザーからの入力を収集し、適切なレポート クラスとデータバインドをインスタンス化するコード。

switch(this.ddlReportType.SelectedItem)
{
    case ReportType.UserActivity:
        var uar = new UserActivityReport(this.StartDate, this.EndDate, this.PageSize);
        this.GridView1.DataSource = uar.GetReport();
        break;
}

レポート コードのリファクタリングについては、単純なものから始めて、レポートごとにクラスを作成することをお勧めします。その後、時間をかけて、共通の要素を削り始め、それらを基本クラスにリファクタリングします。いくつかの本当に明白で簡単に共通の要素を組み合わせることができる場合は、それらをすぐに基本クラスで開始しますが、各レポートを独自のクラスに入れることに焦点を当てます。 .

于 2012-08-10T16:36:17.033 に答える