asp.net-mvc

클라이언트 상호 작용의 양방향에 대해 ViewModel이라는 용어를 재사용한다고 말하고 싶습니다. 야생에서 충분한 ASP.NET MVC 코드를 읽었다면 ViewModel과 EditModel의 차이를 보았을 것입니다. 중요하다고 생각합니다.

ViewModel은 뷰를 렌더링하는 데 필요한 모든 정보를 나타냅니다. 여기에는 정적 비대화 형 장소에서 렌더링되는 데이터와 정확히 렌더링 할 항목을 결정하기위한 검사를 수행하기위한 데이터가 포함될 수 있습니다. 컨트롤러 GET 작업은 일반적으로 해당 뷰에 대한 ViewModel 패키징을 담당합니다.

EditModel (또는 ActionModel)은 사용자가 해당 POST에 대해 수행하려는 작업을 수행하는 데 필요한 데이터를 나타냅니다. 따라서 EditModel은 실제로 액션을 설명하려고합니다. 이것은 아마도 ViewModel에서 일부 데이터를 제외시킬 것이며 관련이 있지만 실제로 다르다는 것을 깨닫는 것이 중요하다고 생각합니다.

하나의 아이디어

즉, Model-> ViewModel에서 이동하는 AutoMapper 구성과 EditModel-> Model에서 이동할 다른 구성을 매우 쉽게 가질 수 있습니다. 그런 다음 다른 컨트롤러 작업은 AutoMapper를 사용하기 만하면됩니다. EditModel은 모델에 대한 속성의 유효성을 검사하고 해당 값을 모델 자체에 적용하는 기능을 가질 수 있습니다. 다른 작업을 수행하지 않고 MVC에 ModelBinders가있어 어쨌든 요청을 EditModel에 매핑합니다.

또 다른 아이디어

그 외에도 최근에 제가 생각했던 ActionModel의 아이디어에서 이런 종류의 작업은 클라이언트가 다시 게시하는 것은 실제로 사용자가 수행 한 여러 작업에 대한 설명이며 하나의 큰 데이터 덩어리가 아니라는 것입니다. 이것은 확실히 관리하기 위해 클라이언트 측에 일부 Javascript가 필요하지만 아이디어가 흥미 롭다고 생각합니다.

기본적으로 사용자가 제시 한 화면에서 작업을 수행 할 때 Javascript는 작업 개체 목록을 만들기 시작합니다. 예를 들어 사용자가 직원 정보 화면에있을 수 있습니다. 직원이 최근에 결혼했기 때문에 성을 업데이트하고 새 주소를 추가합니다. 내부적으로 이것은 목록에 a ChangeEmployeeName및 AddEmployeeMailingAddress객체를 생성 합니다. 사용자가 ‘저장’을 클릭하여 변경 사항을 커밋하고 각 작업을 수행하는 데 필요한 정보 만 포함 된 두 개체 목록을 제출합니다.

더 지능적인 ModelBinder가 필요하지만, 좋은 JSON 시리얼 라이저는 클라이언트 측 작업 개체와 서버 측 작업 개체의 매핑을 처리 할 수 ​​있어야합니다. 서버 측 (2 계층 환경에있는 경우)은 작업하는 모델에서 작업을 완료 한 메서드를 쉽게 가질 수 있습니다. 따라서 컨트롤러 작업은 모델 인스턴스가 가져올 Id와 이에 대해 수행 할 작업 목록을 얻습니다. 또는 행동에 이드가있어 매우 분리되어 있습니다.

따라서 아마도 다음과 같은 것이 서버 측에서 실현 될 수 있습니다.

public interface IUserAction<TModel>
{
     long ModelId { get; set; }
     IEnumerable<string> Validate(TModel model);
     void Complete(TModel model);
}

[Transaction] //just assuming some sort of 2-tier with transactions handled by filter
public ActionResult Save(IEnumerable<IUserAction<Employee>> actions)
{
     var errors = new List<string>();
     foreach( var action in actions )
     {
         // relying on ORM's identity map to prevent multiple database hits
         var employee = _employeeRepository.Get(action.ModelId);
         errors.AddRange(action.Validate(employee));
     }

     // handle error cases possibly rendering view with them

     foreach( var action in editModel.UserActions )
     {
         var employee = _employeeRepository.Get(action.ModelId);
         action.Complete(employee);
         // against relying on ORMs ability to properly generate SQL and batch changes
         _employeeRepository.Update(employee);
     }

     // render the success view
}

올바른 논리 자체를 수행하거나 정보를 사용하여 모델을 호출하기 위해 올바른 IUserAction 인스턴스와 IUserAction 인스턴스를 얻기 위해 ModelBinder에 의존하고 있기 때문에 게시 작업을 상당히 일반적으로 만듭니다.

3 계층 환경에있는 경우 IUserAction은 경계를 가로 질러 촬영하고 앱 계층에서 유사한 방법으로 수행 할 간단한 DTO로 만들 수 있습니다. 해당 레이어를 수행하는 방법에 따라 매우 쉽게 분할되어 트랜잭션에 남아있을 수 있습니다 (Agatha의 요청 / 응답과 DI 및 NHibernate의 ID 맵을 활용하는 것입니다).

어쨌든 완벽한 아이디어는 아니라고 확신합니다. 관리하려면 클라이언트 측에서 JS가 필요하고 아직 프로젝트가 어떻게 진행되는지 확인하기 위해 프로젝트를 수행 할 수 없었지만 게시물은 방법에 대해 생각하려고했습니다. 거기에 다시 돌아와서 나는 내 생각을 줄 것이라고 생각했습니다. 도움이 되었기를 바라며 상호 작용을 관리하는 다른 방법에 대해 듣고 싶습니다.