変更する非常に正当な理由がない限り、デフォルトの名前をそのままにしておくことをお勧めします。ID(あなたの質問が傾いているように見えます)はより柔軟です。
IDの変更
ID はフォームで送信されないため、モデル バインディングを壊さずに必要に応じて設定できます。デフォルトでは、それらは階層的ですが、インラインで上書きできます:
@Html.TextBoxFor( o => o.UserName, new { id = "foo" } )
もちろん手作業です。
大きな懸念が外部の JS/CSS である場合data-*
は、ID ではなく (CSS/jQuery などの) セレクターでクラス名と属性を使用することをお勧めします。
@Html.TextBoxFor( o => o.User.UserName, new { data_role="grand-total" } )
これはまだ手動ですが、説明的であり、ID から独立しています。
ビューでスクリプトのスニペットを使用して、ビュー内で直接最も簡単に利用できるデータでより大きな JS クラスを初期化することがあります。これにより、動的な値を使用して初期化できるようにしながら、スクリプトの大部分を外部ファイルに置くことができます。これは、ID 以外にも役立ちます。
生成されたマークアップとバインディングの変更
参考までに、IDと名前を変更したいとします。
- 独自の
HtmlHelper
拡張メソッドを記述して、必要なマークアップを作成します。おそらく、式をとらない既存のメソッドをラップし、それらに明示的な値を渡して、必要な名前を示すことができます。
ModelBinder
未加工のフォーム コレクションをマップする独自の記述を行います。
- 階層オブジェクトを処理するための戦略を決定します (これが、そもそも命名規則が存在する主な理由です)。
項目 #3 は、命名の実行方法とモデル バインディングのマッピング方法を示すプロパティを装飾することで対処できます。これはすぐに複雑になる可能性があります。
public class UserViewModel
{
// use this metadata to determine how to handle properties on this member
[Flatten]
public UserModel User { get; set; }
public SelectList DescentTypes { get; set; }
public SelectList GenderTypes { get; set; }
}
代替案
User
のプロパティを直接ビュー モデルに追加して、ビュー モデルをフラット化します。ドメイン モデルからビュー モデルを構成しているようです。これは通常、良い考えではありません。ドメインモデルに直接バインドすることの長所/短所を読むことをお勧めします。
ネーミングはお任せください。それは本当に何も傷つけず、生活を楽にします。ヘルパー メソッドを使用することで、クライアント コードで名前/ID を直接操作することを避けることができます。
例えば:
// JavaScript + Razor
var name = "@Html.NameFor( o => o.User.Id )";
alert(name);