この「もの」を長時間使用した後の私の提案：
データ バインディング用のBindingModels (mvc または api)
mvc のビュー用のViewModel (API 内にいくつかの mvc ページがある場合があるため、このための場所を用意しておくとよいでしょう。これは、ドキュメント、紹介ページなど、何でもかまいません。ビューがない場合は、ViewModel をゼロにすることができます) 1 つこれの利点は、Views/web.config で ViewModels 名前空間の参照を持つことができ、API リソースで汚染されないことです。
Web API リソースの ResourceModel 。webapi では、ネストされたリソースはツリー内のどこにでもあるリソースでもありますが、mvc ではそれほど一般的ではないため、リソースに名前を付けるのは非常に理にかなっています。
リソースを受け取りたい場合は、リソース モデルを使用できます。あなたが送っているのと同じものを受け取っていることを忘れないでください。
入力用のカスタム バインドが必要な場合 (これが既定のシナリオです)、バインド モデルが用意されています。
管理目的、ドキュメントなど、mvc ビューがある場合は、ViewModels を使用します。
mvc にフォーム ページがある場合は、BindingModel を POST コントローラーでも使用できます。MVC や WEBAPI への投稿用に別のモデルを用意する必要はありません。特に、モデル バインダーまたはフォーマッターが、同じデータ注釈を使用して同じバインディング モデルを理解し、マッピングできる場合。
場合によっては、リソースといくつかの追加フィールドを使用してバインド モデルを作成する必要があります。継承はあなたの友達です。
場合によっては、複数のリソースと (オプションで追加のフィールド) リソースをプロパティとして持つバインド モデルを作成したいことがあります。
MVC の世界では、「リソース」の概念も使用できますが、あまり一般的ではありません。これは、同じプロジェクトに MVC と Web Api がある場合に便利です。
項目 (フォルダー構造、名前空間など) についてさらにコメントが必要な場合は、お知らせください。短所の長所の経験を共有できることを嬉しく思います。
ああ、忘れていましたが、マッピング戦略は研究する価値があります。私は個人的に独自のマッピングを行っていますが、このロジックを 1 か所にまとめることは非常に貴重です。
編集:非常に素朴な例
ContactViewModel{
string Name {get;}
string LastName {get;}
List<Country> AvailableCountries {get;}
Country Country {get;}
bool IsAdmin {get;}
}
ContactBindingModel{
string Name {get;set;}
string LastName {get;set;}
int Country {get;set;}
}
ContactResourceModel{
string Name { get;set;}
string LastName {get;set;}
Country Country {get;set;}
string IsAdmin {get;}
}