UpdateModelが（モデルプロパティのリフレクションルックアップのために）「高価な」操作と見なされるかどうか、特に大規模なWebアプリケーション（StackOverflowを考えてください）のコンテキストで見た場合はどうでしょうか。
時期尚早の最適化には関与したくありませんが、UpdateModelを使用することは設計上の選択であると考えています。そのため、UpdateModelを使用することが推奨されるかどうかを早期に知りたいと思います。もう1つの（面倒な）選択は、固定プロパティを持つさまざまなドメインオブジェクト用に独自のUpdateModelメソッドを作成することです。
ありがとうございました！
あなたは時期尚早の最適化に従事したくないのが賢明です。特に、この「最適化」は、はるかに高価なプロセッサの時間を優先するためです。
最適化の主なルールは、最初に遅いものを最適化することです。したがって、データベースバックエンドから選択するのではなく、実際にモデルを更新する頻度を検討してください。1/10以下の頻度だと思います。次に、データベースバックエンドから選択するコストとリフレクションのコストを比較します。リフレクションのコストはミリ秒単位で測定されます。データベースバックエンドから選択するコストは、最悪の場合、数秒で測定できます。私の経験では、POSTが非常に遅くなることはめったになく、POSTの場合、通常、リフレクションではなくデータベースに障害があります。最適化の時間のほとんどをGETに費やす可能性が高いと思います。
ネットワーク遅延、データベース呼び出し、および一般的なIOと比較すると、UpdateModel（）呼び出しは簡単であり、私はそれを気にしません。
UpdateModelは、ビューとモデルの間に大量の結合を引き起こすちょっとしたショートカットだと思います。
モデルをより洗練されたもの、または単に別のデータベースプロバイダーに置き換えるオプションが必要なため、「組み込み」モデル（LINQで作成されたオブジェクトをデータベースから直接ビューに渡すことができるなど）を使用しないことを選択します。ただし、ラピッドプロトタイピングにLINQtoSQL（またはADO.NETエンティティ）を使用するのは非常に魅力的です。
私がよく行うのは、MVCアプリケーションを作成してから、「サービス」レイヤーを公開し、それを「モデル」（ドメインのOOビュー）に接続することです。そうすれば、Webサービス層を簡単に作成したり、データベースを交換したり、新しいワークフローを作成したりすることができます。
（そして、必ずテストを作成してDIを使用してください。これにより多くの手間が省けます！）
ロブ