MVCのモデルクラスとデータクラスの理解

Question

Webformsを使用して長年にわたってASP.Netアプリケーションを開発しましたが、私はいくつかのMVCアプリケーションを作成しましたが、フレームワークをフルに使用したことはありません。プロジェクト。しかし、私はMVC構造体を使用していますが、私はまだ古い方法、つまり@ Html.BeginFormなどを使用せず、代わりにユーザーにタグなどを割り当てます。

私は最近別のプロジェクトを開始しましたが、正しいMVC機能を使用したい。

私はデザインパターンのベストプラクティスについて読んでいます。私のソリューションでは、MVCアプリケーション、テスト、およびデータ（データベースに接続するクラスライブラリ）用のプロジェクトがあります。私はEntity Frameworkを使用していませんが、View Modelのクラスを作成する適切な方法についてはまだ疑問に思っています。私はビューにレンダリングしたい

私はクラスのコールユーザーを持っている私のデータライブラリのクラスで

public class User 
{ 
    public long Id { get; set; } 

    [Required] 
    public string Name { get; set; } 

    [Required] 
    public string Email { get; set; } 

    [Required] 
    public long RoleId { get; set; } 
} 

フィールドは名前、電子メール、およびRoleIdためのドロップダウンリストです。したがって、ビュー上のモデルでは、データクラスと同じである必要はありません。モデルビュークラスが正しくありませんか？

public class UserModel 
{ 
    public Data.User User { get; set; } 

    public IEnumerable<KeyValuePair<long,string>> RoleList { get; set; } 
} 

尋ねる理由は、当初、私は常にそのモデルクラスは、私はほとんどの場合、そうでないことをグーグルで読んだことが、あなたのデータクラスと同じであるべきと仮定し、ということです。これは正しいです？

これはビューの正しい実装ですか？あなたのケースでは、あなたがデータモデルが特定され、それの役割を持つユーザーの情報や収集をしているUserModelクラスを、持っているよう

@using (Html.BeginForm()) 
{ 
    @Html.LabelFor(m=>m.User.Name) 
    @Html.TextAreaFor(m=>m.User.Name) 
    <br/> 
    @Html.LabelFor(m => m.User.Email) 
    @Html.TextAreaFor(m => m.User.Email) 
    <br /> 
    @Html.LabelFor(m => m.User.RoleId) 
    @Html.DropDownListFor(m => m.User.RoleId, new SelectList(Model.RoleList, 
    "Value", "Key"),"--Please Select--") 
} 

Answer 1

Modelクラスは、アプリケーションのビジネス面を表し、つまり、あなたのケースではデータベーステーブルに格納されているので、データモデルは通常、所有しているデータベースのテーブルを表します。それが理にかなってほしい。

あなたはまた同じようなことを尋ねる次のポストを参照することができ

私は思う：あなたが取ることができる

https://stackoverflow.com/a/2446051/1875256

Answer 2

最善のアプローチは、あなたがしたい各ビューのモデル（新しいクラス）を作成することですデータを公開する/データをキャプチャするこれは議論の余地がありますが、実際には大きなメリットがあります。何よりもまず、あなたのビューをあなたのドメインに強く結びつけることはできません。つまり、Usersテーブルには20個のカラムがありますが、ログインページ（ユーザ名/パスワード）に2を公開するだけです。第二に、特にMVCのフレームワークとカミソリを使って、バリデーション（サーバー側とクライアント側の両方）や表示名などのようなものに関して大きな助けになります。 また、依存関係階層の管理System.Web.MVC aarrrghへの参照を使用して、すべてのドメインモデルを捨てることは望ましくありません。

ビューモデルを検証してからモデルオブジェクトをドメインオブジェクトに変換して、ビジネスクラスがすべて一貫したドメインモデルで動作するようにする必要があるコントローラでは、「より多くの作業」の部分が入ります。私は完全にビューをバックアップすることができ、粒状のモデルを持っているので、あなたは、上記の見ることができるように

ちょうどあなたのモデルクラスの提案に関して、私はもっとこの

public class UserModel 
{ 
    [Required] 
    [Display(Name = "Name")] 
    public string Name { get; set; } 

    [Required] 
    [DataType(DataType.EmailAddress)] 
    [Display(Name = "Email Address")] 
    public string EmailAddress { get; set; } 

    [Required] 
    [Display(Name = "Roles")] 
    public IEnumerable<KeyValuePair<long, string>> RoleList { get; set; } 
} 

のようにそれを行うだろう（たとは対照的に、 Userオブジェクトへの参照）必要に応じて各フィールドに特定のバリデーションを追加することができます

私は今のところ考えることができないこのルートに行くのにさらに多くの理由があると確信していますが、これはあなたに正しい線に沿って考えさせるでしょう。幸せなコーディング。