ナビゲーションプロパティのAsp.net MVCの検証エラーを克服する方法

Question

シナリオ：

私はEntity FrameworkをしてAsp.Net MVCプロジェクトを実施しています。

class Employee{ 
    public int Id{get;set;} 
    [Required] 
    public string Name{get;set;} 
} 

class Department{ 
    public int Id{get;set;} 
    public string DepartmentName{get; set;} 
    public virtual Employee manager{get; set;} 
} 

ここで、データベースの従業員のリストからマネージャーを持つ新しい部門を作成する必要があります。このため、ビューとコントローラアクションは次のとおりです。

@Html.EditorFor(model => model.DepartmentName) 
@Html.DropDownListFor(model => model.manager.Id, new SelectList(ViewBag.Managers, "Id", "Name")) 


public class DepartmentController: Controller{ 
    private MyDatabaseContext db = new MyDatabaseContext(); 

    [HttpGet] 
    public ActionResult Create(){ 
     ViewBag.Managers = db.Employees.ToList(); 
     return View(); 
    } 

    [HttpPost] 
    public ActionResult Create(Department d){ 
     if(ModelState.IsValid){ 
      d.manager = db.Employees.Find(d.manager.Id); 
      db.Departments.Add(d); 
      db.SaveChanges(); 
      return RedirectToAction("Index"); 
     } 
     else{ 
     //error response. 
     //Error encounters as d.manager.Name field would be null. 
     } 
    } 
} 

問題：プログラム上で実行している場合

ModelState.IsValidは常にfalseあるとして、私は、新しいDepartmentのオブジェクトを作成することはできません。これは、ナビゲーションプロパティmanagerにフィールドNameがあり、フォームを送信するときにnullとなるためです。 Nameが必須フィールドであるため、これはエラーとしてリストされます。

質問：

どのように私は、ナビゲーションプロパティの分野でnullに起因するエラーを克服することができますか？または、このエラーを取り除くためにこのコードを実装する他の方法がありますか？

注：

私はDepartmentオブジェクトを作成するための単なる便利ViewModel異なるを作成しないことに注意してください。私はDRY原則に従うことを好むでしょう。 また、私はEmployeesテーブルの外部キーとなる別のフィールド（managerIdのようなもの）を作成したくありません。なぜなら、オブジェクト指向モデルに注意を払ったデータベースの関連付けは望んでいないからです。 department.managerId [Key]フィールドを渡すことによって、エンティティフレームワークからマネージャオブジェクトを読み取るのではなく、department.managerによってマネージャを取得するのが常によりクリーンです。

ありがとうございます。

Answer 1

Departmentオブジェクトの作成に役立つ別のViewModelを作成したくないことに注意してください。私はDRY原則に従うことを好むでしょう。

この場合のビューモデルの使用は、DRYの原則に違反しません。ビューモデルは、異なる概念（ビューに必要なデータ）を表します。これは、データベーステーブル（ドメインモデル）に必要なデータとはまったく異なるものです。ビューモデルとドメインモデルが、最初にそれらを実装するときに同じプロパティを持つ場合は、が完全に一致しますです。

DRYの原則は、同じコンセプトを複数の場所で繰り返しないようにすることです。

ビューモデルを使用することは、データアクセスレイヤの検証要件がUIレイヤの検証要件とは無関係に異なることを可能にするため、具体的には正しいアプローチです。 UIでドメインモデルを再利用することで、柔軟性が失われ、同じ問題が継続的に発生します。

Answer 2

あなたは教室でこの

public int EmployeeId {get;set;} 

を必要としています。