web-dev-qa-db-ja.com

Web APIでViewModelを作成することは悪い習慣ですか？

それで、私よりも2倍の経験がある職場の誰かが、ViewWebクラスをWeb内に作成してはならないAPI。 （Angular UIを使用しています）

彼の意見では、ViewModelはASP.NET MVCアプローチです。そして、Web APIを使用するときは、それから抜け出す必要があります。

WebAPIでViewModelを使用するための私の引数は次のとおりです。

データベーステーブル

従業員

name | phone | categoryId |...Col15

カテゴリ

categoryId | Description

C＃クラス

Class Employee
{
 public string name {get;set;}
 public phone {get;set;}
 public categoryId {get;set;}
 //...till col15
}

Iページにのみ表示される場合：

 name | phone | categoryId | CategoryDescription

15のプロパティすべてではなく、これらの4つのプロパティのみを持つViewModelクラスをAPIで作成することは理にかなっていますか？このクラスによって返されるJSONには、15のプロパティではなく4つのプロパティのみが含まれ、そのうちの11にはnull値が含まれます。

たとえば100人の従業員のリストがある場合、ViewModelクラスの代わりに元の従業員クラスを使用すると、UIに送信される1100空のjsonプロパティを意味します。

また、元のEmployeeクラスを使用する場合は、次のいずれかを実行する必要がある場合があります。

  1. CategoryDescriptionを元のEmployeeクラスに追加する必要があります
  2. 説明を取得するには、UIから2番目のAPI呼び出しを行います。
c#web-developmentrestapiweb-api
2
SamuraiJack

あなたがやっていることは結構です。クライアントに必要なデータのみを公開する必要があります。

この用語はユーザーインターフェイスのコンテキストで特定の意味を持ち、このコンテキストの外で使用すると混乱を招くため、「ビューモデル」と呼ばないでください。それを「データ転送オブジェクト」と呼んでください、そして誰もが幸せになります。

APIを介してエンティティを直接公開することはお勧めできません。これにより、密結合が作成されます。つまり、ビジネスロジックに少しでも変更を加えると、APIに重大な変更が発生します（逆も同様です）。あなたはそれを避けたいです。

1
JacquesB

原則として、Angularなどのフロントエンドフレームワークは、REST APIに対して使用するのが最適です。これは、ビューモデルがなく、単純にリソースを公開することを意味しますあります。

ただし、その音から、REST APIではなく、フロントエンドアプリケーションのニーズに合わせて調整されたAPIを使用しています。APIについて具体的に言及しているため、これを言います- 省略 15のプロパティのうち11は、この特定のケースではフロントエンドがそれらを必要としないことがわかっているためです。

その場合、APIはフロントエンドアプリケーションビューを本質的に認識しており、ビューモデルを効果的に使用しています。あなたの同僚は、明示的なビューモデルを作成せず、代わりに既存のDTOを再利用しようとしていますが、意図的に空のままにしておくプロパティを使用しているようですが、これは良い習慣ではありません。

したがって、要約すると、「ビューモデルなし」のスタンスは機能しますifREST APIがあります。カスタムリクエストを処理し、フロントエンドが表示する/表示しないものを認識しているためデータを自動的に編集するAPI。「ビューモデルなし」のスタンスは、APIの開発方法と矛盾します。

さらに：

彼の意見では、ViewModelはASP.NET MVCアプローチです。

MVCはModel-View-Controllerの略です。 MVCにはビューモデルがありません。ただし、MVVM（Model-View-ViewModel）にはビューモデルがあります。

この統合があなたの側にあるのか、同僚の側にあるのかはわかりませんが、どちらかの当事者がMVCとMVVMを区別できない場合、ビューモデルの使用（またはその欠如）を生産的に議論することはほぼ不可能です。
少なくとも、間違った名前（viewmodelとmodel）を使用しているため、他の人があなたの説明に基づいて正確なフィードバックを提供するのは非常に困難です。

1
Flater

はい、それは悪い習慣です。

基本的に、Javascriptクライアントアプリケーションからサーバー側にロジックを移動します。

これは、クライアント側のロジックがほとんどまたはまったくないページリクエストを作成する場合に適切に機能しますが、少なくともすべてのプレゼンテーションロジックがクライアント側であることが想定され、さまざまなメリットを活用できる単一ページアプリがある場合は機能しません。 。

したがって、最初の例では、切り捨てフィールドを使用してEmployeeViewModelを作成した後、フロントエンドにこれらのフィールドの1つが必要になった場合、フロントエンドとバックエンドの両方を編集する必要があります。

従業員をカテゴリの説明で充実させる2番目の例では、クライアントは情報を個別に要求し、それをメモリに保持し、従業員に参加させ、ドロップダウンなどで使用することができます。

いずれの場合も、サーバーにビューモデルを追加すると、クライアントサイドコードでの柔軟性と使用可能なオプションが減少します。

1
Ewan

私によると、Web APIプロジェクトでリポジトリパターンを使用している場合、その場合は、フロントエンド側からデータベースと直接対話するためにビューモデルを使用することをお勧めします。それ以外の場合は、ビューモデルを使用せずに操作を実行できます。

0
Ishan Shah