UI 래퍼를 뷰에 전달하면 어떤 이점이 있나요?

Question

내가 본 대부분의 MVC 샘플은 다음과 같이 뷰 인스턴스를 컨트롤러에 전달합니다.

public class View  
{  
Controller controller = new Controller(this);  
}

다음과 같이 컨트롤러가 관심 있는 속성 및 이벤트에 대한 액세스를 제공하는 클래스를 전달하면 어떤 이점이 있습니까?

public class UIWrapper
{
private TextBox textBox;

public TextBox TextBox
{
get {return textBox;}
}

public UIWrapper(ref TextBox textBox)
{
this.textBox = textBox;
}


public class View
{
UIWrapper wrapper = new UIWrapper(this);
Controller controller = new Controller(wrapper)
}

Answer 1

아키텍처에 따라 다릅니다.모두 동일한 계층에 있다면 래퍼 없이도 진행할 수 있지만 아마도 View가 구현하는 인터페이스를 컨트롤러에 전달할 것입니다.기능적으로나 결합 관점에서 인터페이스 접근 방식과 래퍼 접근 방식은 동일합니다.

그러나 UI가 한 계층에 있고 컨트롤러가 다른 계층에 있는 경우 전체 View 개체를 전달/직렬화하는 것은 어색하거나 비효율적일 수 있습니다.이와 같은 경우 DTO를 앞뒤로 전달하는 것이 더 쉽고 효율적일 수 있습니다.

나는 DTO 접근 방식을 선호하는 경향이 있습니다. 왜냐하면 아키텍처가 확장되면 직렬화 및 역직렬화만 하면 되기 때문입니다.

또한 뷰가 복잡하고 컨트롤러와 주고받을 데이터 조각이 많으면 긴 매개변수 목록 문제를 해결하기 시작할 수도 있습니다. 매개변수 객체 소개 어쨌든 이는 본질적으로 DTO입니다.

한 가지 더 짚고 넘어가야 할 점은 다음과 같습니다.복잡한 뷰의 경우 컨트롤러는 결국 많은 데이터 조각을 뷰의 다양한 텍스트 상자 및 기타 UI 컨트롤에 매핑해야 합니다.반대의 경우도 마찬가지입니다.View는 결국 많은 컨트롤에서 데이터를 가져와 컨트롤러의 다양한 메서드에 전달합니다.

나는 이 둘을 분리하는 것을 좋아한다.나는 Views에 DTO를 제공하고 각 데이터 조각을 "플러그인"하고 "플러그아웃"할 위치를 아는 것이 View의 임무라고 생각합니다.어쨌든 데이터에 관한 한 뷰와 컨트롤러는 모두 DTO에만 연결됩니다.

Answer 2

님의 좋은 게시물 시리즈가 있습니다. 제레미 밀러 MVC/MVP 트라이어드와 관련하여.특히 당신이 관심을 가질 수 있는 사항은 다음과 같습니다. 6부 뷰와 컨트롤러 사이의 통신에 대해 자세히 설명합니다.