ASP MVC 4 컨트롤러의 객체 상태를 관리합니다.

Question

저는 MVC를 처음 사용하고 있으며 상태 및 객체 지속성에 개념적 문제가있어 다른 사람이 내 생각을 정리할 수 있기를 바랍니다.

주문을 관리하는 방법을 제공하는 원격 웹 서비스가 있습니다. 주문은 예상대로 헤더와 라인으로 구성됩니다. 라인에는 추가 요구 사항이있을 수 있습니다.

(웹 서비스 스키마에서 xsd2code를 사용하여) 내 도메인 개체를 만들었습니다. 웹 서비스 호출과 개체 직렬화가 모두 정상적으로 작동합니다. 나는 DAL/BLL 레이어를 만들었고 WinForms 테스트 베드 앱 프런트 엔드를 사용하여 모두 작동 테스트를 거쳤습니다.

Automapper를 사용하여 도메인 개체에서 매핑 된 뷰 모델 개체가 있습니다. 순서는 라인 등을 갖춘 단일 웹 서비스 메서드에서 반환되기 때문에 내가보기에 모델로이 통과하는 것처럼 나는 OrderViewModel 생략하는 경우는 내가 궁금하네요 첫째

public class OrderViewModel 
{ 
    public OrderHeaderViewModel OrderHeader { set; get; } 
    public List<OrderLineViewModel> OrderLines { set; get; } 
    public List<OrderLineAdditionalViewModel> OrderLineAdditional { set; get; } 
    public List<OrderJustificationViewModel> OrderJustifications { set; get; } 

} 

을 다음과 같이 나는 OrderViewModel이 내가 필요한 것보다 훨씬 많은 데이터를 전달하고있다. 조회는 OrderHeader 또는 OrderLines 등 만 필요하며 전체 주문은 필요하지 않습니다.

이제 개념적인 문제는 컨트롤러와 뷰 및 개체 지속성에 있습니다.

내 주문 컨트롤러에는 webservice에서 주문로드를 수행하고 도메인 개체를 OrderViewModel 개체에 매핑하는 세부 작업이 있습니다.

public ActionResult Details(string orderNumber) 
    { 

     OrderViewModel viewModel = new OrderViewModel(); 
     var order = WebServiceAccess.LoadOrderByOrderNumber(orderNumber,"OBOS_WS"); 

     viewModel = AutoMapper.Mapper.Map<BusinessEntities.Order, ViewModels.OrderViewModel>(order); 

     return View(viewModel); 
    } 

하지만 주문/Details.cshtml은 페이지 레이아웃 및합니다 (LinesView에 대한 같은 Ajax를 사용하여 나는 HeaderEdit의 Headerview를 교환) 두 부분 헤더에 대한 페이지와 라인에 통화가 있습니다

모델을 기본 세부 정보 컨테이너 페이지로 보낸 다음 RenderPartials로 전달하는 중, 모델이 기본 세부 정보 페이지로 전달되어야한다고 생각하지 않습니다. 모델은 DetailsHeaderViewPartial, DetailsLinesViewPartial에서만 필요하므로 모델 대신 @RenderAction을 사용하여 모델을 헤더로 전달하는 것이 좋습니다./선보기 대신.

그러나, 순서는 반환 PartialView의 모델로 전달하는 ActionResult I이 (가) ActionResult HeaderDetails (가능 객체 OrderViewModel 검색 할 수있는 방법 세부 사항())/LineDetails() 컨트롤러의 방법에서 웹 서비스에서 검색 (..., 모델)?

사용자 세션을 사용하여 컨트롤러의 여러 작업에서 사용할 수 있도록 Order ViewModel을 저장해야합니까?

이 단계에서 이동하면 사용자가 주문을 유지 관리 할 수 ​​있습니다 (행 추가/제거 - 머리말 편집 등). 주문을 저장하는 webservice 호출이 완료되기까지 몇 초가 걸릴 수 있으므로 사용자가 주문을 완료하면 save 메서드를 호출하는 것이 좋습니다. 그러므로 나는 진행중인 주문을 현지에서 어딘가에서 계속 유지하고 싶습니다. 사용자 세션?

조언에 대해 감사드립니다. ViewModels에 대한 상태 관리에 대해 머리 숙여지면 백만 개의 블로그 게시물을 읽지 않고 실제로이 글을 쓸 수 있습니다.

Answer 1

실제로 몇 가지 질문이 있으니 최대한 최선을 다해 답변 해 드리겠습니다.

1) 뷰 모델로 분배 : 아니오라고 말하고 싶습니다.뷰 모델은 뷰를 채우기 위해 필요한 데이터를 나타냅니다. 도메인 모델 객체와 동일한 컨테이너로 뷰 모델을 사용하는 것 같습니다. 따라서 도메인 모델을 뷰에 전달하면 더 많은 데이터를 전달하는 것이 원래의 우려 인 반면, 실제로 필요로하는 것은 도메인 모델을 전달해야하는지 묻는 것입니다.

보기 모델을 사용하지 않고 뷰 모델의 속성을 다시 방문합니다. 복잡한 도메인 객체를 가져 와서 뷰 모델의 속성을 채우는 데 필요한 속성 만 사용하고 매핑 논리를 만듭니다 (자동 또는 개별적으로).

요약 :보기에 필요한 것만보기 모델을 작성하고 해당보기 모델을 채우는 데 매핑 논리를 작성하십시오.

2) 이것은 특정 시나리오를 자세히 설명하기 전에 모범 사례에 불과합니다.

아키텍처에 BLL 및 DAL이 있다고 설명합니다. 그렇다면 컨트롤러의 객체를 유지하지 않아야합니다. 컨트롤러는 기존의 데이터베이스에 대해서도 전혀 알지 못하며 컨트롤러에 사용 된 개체는 스스로를 유지하는 방법을 모를 수 있어야합니다. 컨트롤러와 웹 서비스간에 이동하는 객체는 엄격하게 데이터 전송 객체 (DTO) 여야합니다. 당신이 DTO를 구성하는 것에 익숙하지 않다면, 나는 당신이 약간의 연구를하고 당신의 솔루션에 그것들을 구축하려고 노력할 것을 강력하게 제안합니다. 뷰 모델 객체, 도메인 객체 및 데이터 전송 객체 간의 차이점을 개념적으로 파악하는 데 도움이됩니다.

3) 세션에 주문 개체를 저장하려고 시도하지 않습니다. 뷰 내에서 부분 뷰를 분할하는 방법을 다시 분석하여 필요한 방식으로 매개 변수 인 ordersviewmodel로 작업을 호출 할 수 있습니다. 불필요하게 뷰를 부분 뷰로 분해하는 것처럼 들립니다.

4) 뷰 모델 객체에 대한 상태 관리와 관련이 없습니다. 뷰 (여러 부분 뷰로 구성 될 수 있음)는 뷰 모델에서 제공하는 특성을 기반으로 채워집니다. 사용자는 개발 한 UI를 사용하여 변경할 수 있습니다. 웹 서비스에 대한 호출을 최적화하기 위해 모든 변경을 완료 한 후에 만 ​​저장하려는 욕구를 나타내므로 제출을 클릭하면 뷰 모델의 필드를 다시 채워 넣기 만하면됩니다. 이제 사용자 변경을 나타내는 orderviewmodel의 "상태"가 있습니다. 이 객체를 DTO로 변환 한 후 (위에서 말한 것처럼) 또는 도메인 객체에 매핑하여 웹 서비스에 보낼 수 있습니다.

1 최종 메모. automapper를 사용하여 도메인을 뷰 모델에 매핑합니다. 뷰 모델이 너무 복잡하고 뷰 모델을 구성하여 도메인 객체를 에뮬레이트하여 자동 작성자가 명명 규칙에 따라 매핑 할 수 있으므로 필요하지 않은 사항이 포함되어 있다고 가정합니다. Automapper에는 표준 동일한 이름 속성 밖에있는 복잡한 (사용자 정의) 매핑을 수행하는 API가 있습니다. 오토 맵퍼가 뷰 모델을 특정 방식으로 만드는 것을 제한하지 마십시오.

희망이 있습니다.