MVP 및 USERCONTROL 및 호출

Question

나는 사용자 컨트롤과 관련하여 MVP STUF 주위에 머리를 잡으려고 노력하고 있습니다. .NET WinForms (또는 그에 가까운 것)를 사용하고 컨트롤러 패턴을 감독하고 있습니다 (글쎄요 :).

사용자 컨트롤 자체는 MVP 응용 프로그램의 일부입니다 (뷰와 관련 발표자 등이 있습니다). 발표자는 항상 먼저 시작되며 모델을 시작한 다음보기를 시작합니다. View는 UI를 구축하며, 그 중 일부는 New The UC가 될 것입니다.

이제 (Form) 발표자는 UC 발표자에 대해 알아야하지만보기가 어떻게 구성되는지에 대해 아무것도 모른다고 생각합니다. 예를 들어 양식 발표자는 UC가 양식의 컨트롤 컬렉션의 일부라는 것을 알지 못합니다.

또한 디자인 경험을 변경해서는 안됩니다. iow view (form)의 개발자는 도구 상자에서 사용자 컨트롤을 선택하고 양식에 놓을 수 있어야합니다.

그래서 내 질문에. 첫째, 내 가정이 정확합니까? 다소 잘못 인도 되었습니까? 엉망이되다? WTF 생각하고 있습니까?

둘째, Form View가 UC보기를 호출하는 것이 옳고 (충분합니까?), 양식 발표자가 UC 발표자를 호출하고 UC View에게 발표자가 무엇인지 알려주는 메커니즘이 있습니까? 이것은 내 "발표자 첫 번째"규칙을 깨뜨리지 만 어떻게 해야할지 잘 모르겠습니다.

다른 생각, 제안, 의견은 기꺼이 받아 들여졌습니다.

-Nwahmaet

Answer 1

발표자는 프레젠테이션 계층에서 "자율 상태"로 생각해야합니다. 이는 모델 상태에 대한 뷰의 프레젠테이션이 동기화되도록하는 책임이 있음을 의미합니다. 내가 이것을 가져 오는 이유는 MVP의 "패턴"이 종종 독단적 인 관점에서 길을 잃기 때문입니다. 어떻게 물건을 분리해야합니다. 이것이 Martin Fowler가 시도하기로 결정한 이유 중 하나 인 것 같습니다. MVP 주변의 용어를 명확히하십시오 무늬.

MVP의 내가 좋아하는 맛은 다음과 같습니다 수동적 견해, 그래서 내 대답은 그에 근거합니다.

수동 뷰 패턴을 사용하여 복합 사용자 컨트롤 및 양식을 매우 자주 구현합니다. 본질적으로 3 가지 다른 구성이 있습니다.

1. 계층 구조의 모든 사용자 컨트롤에 대한 한 명의 발표자. 인터페이스를 사용하여보기를 평평하게하십시오.
2. 복합 트리의 각 사용자 컨트롤에 대한 한 명의 발표자. 각 부모 발표자는 자식 발표자를 인스턴스화하고 초기화 할 책임이 있습니다. 사용자 컨트롤은 설계 시간에 생성되며 발표자없이 작동 할 수 있습니다 (프레젠테이션 동작 없음).
3. 복합 트리의 각 사용자 컨트롤에 대한 한 명의 발표자. 모든 발표자는 더 높은 레벨 컨트롤러 클래스를 통해 느슨하게 결합됩니다. 컨트롤러 클래스는 발표자를 구성하고, 배선하고, 이벤트를 조정할 책임이 있습니다.

그것은 나에게 최후의 수단의 해결책이지만 (복잡성 때문에) 마지막 옵션은 당신이 찾고있는 솔루션이라고 생각합니다.

Answer 2

나는 내가 작업중 인 응용 프로그램에서 몇 달 동안이 정확한 문제에 반대했습니다. 내가 최근에 왔다는 결론은 많은 경우 패턴을 "파괴"하지 않고 창과 사용자 제어 레벨 모두에서 MVP 패턴을 적용하는 것이 불가능하다는 것입니다.

이에 대한 내 생각은 사용자 컨트롤이 View 구현의 일부이며 발표자는 View 구현 내부에서 무슨 일이 일어나고 있는지 알지 않아야한다는 것입니다. 즉, Extension의 창 수준 발표자가 사용자 컨트롤의 발표자에 대해 알지 않아야합니다. 그러므로 전자에 의한 후자의 인스턴스화를 포함하여 그들 사이의 의사 소통은 없어야한다. 사용자 컨트롤 발표자는 Window View 구현의 일부라고 주장 할 수 있으므로 Window View는 사용자 컨트롤 발표자를 인스턴스화 할 수 있습니다. 그러나 견해는 그들을 인식하지 않아야하기 때문에 발표자가 필요로하는 모델 클래스를 주입 할 수 없습니다.

제가 도착하고 있다고 생각한다는 결론은 모든 사용자 컨트롤이 뷰 구현에 따른 것이므로 더 큰 패턴의 뷰 사일로 내에 완전히 포함되어야한다는 것입니다. 따라서, 그들은 자신의 발표자를 갖지 못하게합니다. 적어도 제어 구현 자체와 번들로 번들리지 않았습니다. 대신 뷰 인터페이스에 노출 된 통과 필드를 통해 부모 창의 발표자가 간접적으로 조작해야합니다. 요컨대, 사용자 컨트롤은 자체 인터페이스가 아니라 부모보기에 의해 구현 된 일반적인 패스 스루 인터페이스를 통해 발표자에게 노출됩니다. 이것을 "부분보기 인터페이스"라고 부릅니다.

그런 다음 발표자는이 부분 뷰 인터페이스와 함께 작동하는 재사용 가능한 하위 프리 센터 클래스의 인스턴스와 모델의 관련 부분을 포함 할 수 있습니다. 이렇게하면 컨트롤을 사용해야 할 때마다 발표자 코드를 다시 작성하여 모델에서 번역 할 수 있으며, 컨트롤 발표자에게 정보를 전달하기 위해 Window View가 모델에 대해 알 필요가 없습니다.

이것이 효과적으로 수행하는 것은 데이터 모델에서 모듈로서 사용자 컨트롤을 더 분리하는 것입니다. 사용자 컨트롤을 전체적으로 View 구현의 요소로 생각하면 의미가 있습니다. 재사용 가능한 단위로서, 그것은보기 기능이며, 그 일부는 데이터 모델에 연결되어 있지 않아야합니다.

Answer 3

귀하의 질문은 다양한 계획이 적용될 수 있다는 일반적으로 일반적입니다.

이 경우 내 추측은 관찰자 패턴을보아야한다는 것입니다.

해당보기를 사용하는 모든 것이 구현되는 인터페이스가 있습니다. 그런 다음 응용 프로그램이 해당 인터페이스 모음으로 초기화되면 스스로 등록합니다. 해당보기를 업데이트 해야하는 모든 명령은 각보기가 업데이트되어야한다는 알림을 수집 할 수 있습니다.

일반적인 예와 달리보기는 사용자 컨트롤입니다. UI 요소가 해당 인터페이스를 구현할 수있는 유연성이 있으므로 사용자 컨트롤 외에 대화 상자, 전체 양식 등을 사용할 수 있습니다.

마지막으로 사용자 컨트롤은보기가 아니라보기의 구현이라는 것을 기억하십시오. 어떤 체계를 채택하든 원하는만큼의보기를 정의하고 사용자 제어가 해당 인터페이스를 구현할 수 있습니다.