3

MVC でのコントローラーの仕事と混同し始めていると思います。

5 つの機能を公開するサービスがあります。

  • キュー内のパッケージを一覧表示する
  • パッケージを取得
  • パッケージを削除
  • パッケージを受け入れる
  • パッケージを拒否

私の ASP.NET MVC コントローラーはこのサービスに依存しており、通常はアクションでサービス呼び出しを実行できます。私は今のところ幸せです。

次に、ViewModel の結果を構築します。コントローラー内でこれを行うと、コントローラーには爆発的な依存関係リストが作成されます。追加された各アクションは、ビューモデルを構築するために依存関係を増やし、これらはすべてコントローラーによって継承されます。私はこれがあまり好きではありません。N個の異なるビューモデルビルダーに依存するこのコントローラーを構築していますが、リクエストごとにそのうちの1つだけを使用しています。

そこで、これらをすべて引き出して、各ビュー モデルに固有のアクション フィルターを適用することを考えていました。まだやってませんが、大丈夫そうです。

これが私に提起している問題は、次のとおりです。コントローラーの責任は何ですか? ビュー モデル ビルドをフィルターにプルすることになった場合、コントローラーは、ルートにサービス コールを実行させる (そしてフィルター プラグインを提供する) ことしかできません。代わりに、各ビューモデルの構築をコントローラーに任せると、混乱してしまいます。

コントローラーではなく、リクエストごとにアクションをインスタンス化したいようですが、フィルターを悪用してそれを取得しているだけですか?

4

2 に答える 2

4

専用のViewModelsとPoco-Modelsはありますか？この場合、ViewModel内のサービスからのデータを処理できます。私はこの騒動に非常に満足しています。

public class PackageViewModel()
{
    public PackageDetail{get;set;}
    public int PackageID{get;set;}
    public List<Package>Packages{get;set;}
    public string SomeFilterCriteria{get;set;}

    publlic void FillPackageList(IPackageService packageService)
    {       
        Packages = packageService.GetPackages(SomeFilterCriteria);      
    }
}

コントローラの場合：

public ViewResult ListPackages(PackageViewModel model)
{
    model.FillPackageList(PackageService);
    return View("ListPackages",model);

}

「ビューモデルビルダー」の意味がわかりません。

于 2009-08-06T19:07:38.230 に答える
2

コントローラーは、ビューで発生させたいすべてのアクションを調整することになっています。このロジックをアクション フィルターに引き出した場合でも、ルート リクエストごとにロジックを実行しているため、ケースがよりクリーンになります。

于 2009-08-06T18:11:48.980 に答える