web-dev-qa-db-ja.com

ビューモデルを作成するためのファクトリクラスは必要ですか？

私の同僚は、ASP.NET MVCソリューションでビューモデルオブジェクトを作成するためにファクトリクラスを使用することを提案しました。これは、ビューモデルをアプリで構築する方法の設計と保守性に役立つという考えです。

他の誰かがこれを経験したことがあるかどうかを知りたかった。私はいくつかの研究を行いましたが、この実践についてはほとんど見つかりませんでした。

現在、コントローラレベルでビューモデルオブジェクトを作成しています。

public ActionResult Index()
{
    return this.View(this.BuildIndexViewModel());
}

したがって、this.BuildIndexViewModel（）は、viewmodelクラス（明らかに:)の作成を担当します。ただし、以下の可能性について検討しています。

public ActionResult Index()
{
    return this.View(ViewModelFactory.CreateIndexViewModel());
}

これは興味深いアイデアですが、100％確信しているわけではありません。これについて他の人の意見に興味がありました。

designasp.net-mvc
17
Jason Evans

この場合、私が従うべき最良のガイダンスは [〜＃〜] grasp [〜＃〜] 原則であると言います。特に、オブジェクト作成の割り当てに関する4つの基準を見てください。

一般に、クラスBは、次の1つ、できればそれ以上が当てはまる場合、クラスAのインスタンスを作成する責任があります

  • BのインスタンスはAのインスタンスを含むか、複合的に集約します
  • BのインスタンスはAのインスタンスを記録します
  • BのインスタンスはAのインスタンスを密接に使用しています
  • BのインスタンスにはAのインスタンスの初期化情報があり、作成時に渡します。

コントローラークラス（B）はそのリストのアイテム＃3と＃4（およびビューモデルがPOSTされた場合は＃2）に一致するため、ビューモデル（A）の構築動作を実行するための非常に賢明な場所です。私が見ているように、その建設行動を専門家クラスに抽出させざるを得ない理由は2つだけです。

  • [〜＃〜] dry [〜＃〜] -2つ以上のコントローラーがビューモデルの構築動作を共有する必要がある場合、それを別個のコンポーネントにカプセル化すると、コードの再利用が容易になり、重複を回避できます。
  • 構築動作がリポジトリ、バリデーターなどの他のシステムコンポーネントに依存していて、この結合をコントローラー自体に導入したくない場合（GRASP用語では、純粋な製造）。

GRASPの4つのオブジェクト作成基準を振り返ると、そのリストで追加のティックが得られた場合にのみ、別のファクトリーに動作を抽出します。そうでなければ、そうすることに価値はありません。

お役に立てば幸いです。

8
MattDavey