ViewModelまたはViewの責任を描画ロジック

Question

昨日私は、ViewModelとViewの責任について私の仕事のパートナーの一人と少し議論しました。ビューの編集/新規モードなど、さまざまなコンテキストで変更されるテキストがあります。チームのプログラマーの一つは、このように気にいらを書いた：

@if (Model.IsNew) 
{ 
    @Resources.New; 
} 
else 
{ 
    @(Resources.Editing + " " + Model.Name); 
} 

私はこのロジックがViewModelに責任であることを守る：

のViewModelには：ビューで次に

public string PageTitle => IsNew ? Resources.New : $"{Resources.Editing} {Name}"; 

：

<h2> 
    @Model.PageTitle 
</h2> 

しかし、私の同僚はそれが印刷ロジックであることを守っているので、Viewには責任があります。

どちらも私たちの議論がありますが、私はコミュニティの意見を知りたいと思います。

Answer 1

あなたがMVCパターンのdefinitonを調べる場合は、あなたがそれを見ることができます：

ビューがモデルの変化に基づいて、ユーザに新しい出力を生成します。

はあなたが適切 Separation of Concerns原則を遵守したい場合は、ビューはUIにデータを表示するための責任があることを意味し、このモデルはあなたが見ることもたらすデータのプロパティバッグとしての略です。

あなたのビューの基本的なモデルはあなたのビューモデルです。これにより、このプロパティをviewmodelとコントローラ/ viewmodel builder/service /に設定するロジックに入れます。

これをさらに防御するには、ビューのコードをunit/integarationテストするのがどのくらい簡単か教えてください。結果を表明するだけの新しいテストをもたらすこの論理？あなたは可能性が分離懸念を維持するために、さらにこのテーマを拡張するには...私に

を全く真のビジネス価値をもたらしていない：

• は、このような新しい、編集、などなどのモード、のために非常に薄く、集中コントローラを作成します。
• これらのモードごとにビューモデルが分かれているため、ビューモデルはビューと1-1の関係にあります。

これらはすべて意見がありますが、すべての人に適した環境を作成してください。

Answer 2

私はこの論理がビューに関連していると言いたいと思います。私たちはページのタイトルについて話しているからです。

しかし、ネストされたステートメントを作成する代わりに、このために、htmlヘルパー、f.iを作成します。 Html.PageTitle(Model)。

Answer 3

ViewModelコードは、Kayessと完全に同意します。ビューは、表示される内容を把握する必要はありません。

@ビュー{@}を見ると、私の背骨の上に震えがあります。常にバグがあり、不確定なコードです。