asp mvc 및 nhibernate를 사용하여 참조 (dropdownList)로 모델을 효율적으로 업데이트하는 방법

Question

nhibernate 및 asp mvc2를 사용하여 웹 응용 프로그램 (응용 프로그램 포트폴리오)을 개발하기 시작했습니다.

응용 프로그램의 카테고리를 올바르게 변경하는 데는 몇 가지 어려움이 있습니다. 여기
내 모델입니다 :

public class Application 
{ 
    public virtual int Application_ID{ get; private set; } 
    public virtual string Name { get; set; } 
    public virtual Category Category { get; set; } 
} 
public class Category : ILookupItem 
{ 
    public virtual int Category_ID { get; set; } 
    public virtual string Name { get; set; } 
} 

내 뷰 모델 :

public class ApplicationEditModel 
{ 
    public Application Application { get; set; } 
    public SelectList Categories { get; set; } 
} 

내 양식 :

<% Html.BeginForm(new {id= Model.Application.Application_ID }); %> 
<table> 
<tr> 
    <td><%=Html.LabelFor(x => x.Application.Application_ID)%></td> 
    <td><%=Html.DisplayFor(x=>x.Application.Application_ID) %></td> 
</tr> 
<tr> 
    <td><%=Html.LabelFor(x=>x.Application.Name) %></td> 
    <td><%=Html.EditorFor(x=>x.Application.Name) %></td> 
</tr> 
<tr> 
    <td><%=Html.LabelFor(x=>x.Application.Category) %></td> 
<td><%=Html.DropDownListFor(x=>x.Application.Category.Category_ID,Model.Categories,"Select a category") %></td> 
</tr> 
<tr><td><input type="submit" /></td></tr> 
</table> 
<% Html.EndForm(); %> 

내 컨트롤러 액션 :

[HttpPost] 
    public ActionResult Edit(int id, FormCollection collection) 
    { 
     Application app = _service.FindById(id); 
     TryUpdateModel<Application>(app, "Application"); 
     _service.CommitChanges(); 
     return RedirectToAction("Index"); 
    } 

내가 엉덩이를 수 이가 보인다

2에서 변경된 Core.Model.Category의 인스턴스의 식별자

3 : 새 범주를 IGN,하지만 난 다음과 같은 메시지가 다른 카테고리로 변경하는 경우 defaultmodelbinder가 새 범주에 새 새 키를 할당하는 대신 지정된 범주의 키를 업데이트하기 때문입니다.

모든 참조로 엔티티를 업데이트하는 올바른 방법은 무엇입니까?
사용자 정의보기 모델을 사용하여 컨트롤러에서 바인딩 한 다음 내 도메인 모델에 매핑 할 수 있습니다. 그러나 그것이 나에게 너무 많은 일을 줄 것이라는 것을 두려워한다. (결국 엔 내 응용 모델에서 약 100 개의 속성, 30 개의 참조 및 5-6 개의 목록을 갖게 될 것이다.)
기존 도메인 모델을 업데이트하려면 Automapper가 유용 할 수 있습니까?
어떻게 이런 종류의 업데이트를 처리하고 있습니까?

Answer 1

매우 간단한 응용 프로그램이 아니라면보기 및 도메인 모델 모두 동일한 모델을 사용하기가 매우 어렵습니다. 별도의 도메인 모델을 갖는 또 다른 이유는 100 개의 모든 속성에 대해 거대한 형식을 표시하는 것은 사용자에게 친숙하지 않다는 것입니다. 다른 작업에 대해 사용자에게 다른 양식을 표시하는 것이 좋습니다. 어쨌든 한 도메인 엔터티에 대해 다른 뷰 모델로 끝납니다.