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

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

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

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

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

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

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

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

design asp.net-mvc

— ジェイソン・エヴァンス
ソース

私はその利益が正直であることを理解するのに苦労しています。オブジェクトの構築を隠すためにファクトリを使用しますが、この場合はなぜですか？

— -CodeART

BuildIndexViewModelメソッドは既にファクトリーメソッドであり、おそらくコントローラー専用です。それを別のファクトリクラスに抽出する唯一の理由は、別のコントローラでそれを再利用することです。

— MattDavey

二人ともこれについて私と同じ考えを共有しているので、私は一人ではないことを嬉しく思います:) @MattDaveyアイデア冗長。このトピックが職場で再び取り上げられたときに、これを共有します。

— ジェイソンエヴァンス

個人的には、ビューモデルタイプは、それ自体を構築するプロセスの専門家であることが望まれます。建設はあなたがかもしれない。その場合には、他の応用分野（例えばリポジトリ）の知識、必要な場合は、専門知識を他の場所に置く必要があることだけですしたい :)ダムのviewmodelを維持するために仲介を

— MattDavey

@MattDavey：これらの2つのコメントを、私が投票できる答えにまとめることができますか？

— -pdr

この場合、従うべき最善のガイダンスはGRASP原則であると思います。特に、オブジェクト作成を割り当てる4つの基準を見てください。

一般に、クラスBは、次のいずれか、またはできればそれ以上が当てはまる場合、クラスAのインスタンスの作成を担当する必要があります。

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

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

GRASPのこれら4つのオブジェクト作成基準を振り返ってみると、そのリストで余分なチェックを獲得した場合にのみ、動作を別のファクトリーに抽出します。そうでなければ、そうすることには何の価値もないでしょう。

お役に立てば幸いです！

— マット・デイビー
ソース