7

스윙 응용 프로그램에서 MVC 패턴을 적용하려고합니다. 그러나 패널의 계층 구조가 중첩되어 있으므로 두 가지 주요 문제에 직면하고 있습니다. 부모 -> 어린이 -> 그랜드 아이 -> 그랜드 그랜드 아이.스윙 MVC - 이벤트 Propagation 및 데이터 공유

문제 1 : 이러한 계층 구조가있을 때 컨트롤러와보기간에 데이터를 전송하는 방법? 제가 부모님에게서 자식에게 데이터를 전달하면 많은 중복이 생기고, 한 아이를 바꾸면 모든 부모가 변화를 요구할 것입니다. 뷰가 db의 데이터에 직접 액세스하는 것을 원하지 않고 컨트롤러를 통해서만 뷰에 데이터를 전송하려고합니다.

문제 2 : 이러한 계층 구조에서보기에서 컨트롤러로 이벤트를 전파하는 방법은 무엇입니까? PropertyChangeListener를 사용하려고 생각 중입니다. 컨트롤러에 의해 액션을 취해야한다면 View는 firePropertyChange 이벤트를 발생시킵니다. 컨트롤러는 이러한 이벤트를 수신하고 일부 작업을 수행합니다. 그러나 다시이 작업을 계층 구조에 적용하면 코드가 중복됩니다.

  1. 각 패널 컨트롤러를 사용하려면하지만이 방법으로 내가 컨트롤러의 많은 끝날 것입니다 :

    내가 도움이 될 수있는 세 가지 아이디어가 있습니다.
  2. 뷰와 컨트롤러 간의 통신을 제공하는 중재자 디자인 패턴을 사용하십시오.
  3. Central Reciever & 알리미를 사용하면보기에서 모든 속성 변경 이벤트를 수신하고 관심이있는 컨트롤러에 알립니다. 하지만 이것은 내 두 번째 문제를 해결할 것입니다 :

제 3의 아이디어의 그림을 보려면 아래 다이어그램을 참조하십시오. 두 번째 케이스의 경우 중재자가 센터에 올 것입니다.

누구든지 이러한 문제가 더 나은 방법으로 구현되었는지 평가하고 알려주십시오.

당신은 다른보기 모델의 속성을 포함하는 뷰 모델을 가질 수

enter image description here

+2

Marting Fowler는 프리젠 테이션 아키텍처에 대한 일련의 기사를 게시했습니다. (유용한 링크가 없으므로 미안하지만 맨 위 검색을 수행해야합니다 :-) – kleopatra

+0

일부 _model-view-presenter_ (MVP) 링크가 인용됩니다 [ 여기] (http://stackoverflow.com/a/15181906/230513). – trashgod

답변

1

나는 문제 1에 대한 제안이있다. 컨트롤러 메소드에서 모델 바인더가 모든 속성을 바인딩하기 때문에 부모 ViewModel 만 받아 들여야합니다.

public class GrandChildViewModel{ 
    public Int32 SelectedDropDownItem { get; set; } 
    public List<Foo> ListOfFoo { get; set; } 
} 

public class ChildViewModel{ 
    public String Name { get; set; } 
    public Int32 Age { get; set; } 
} 
public class FatherViewModel{ 
    public ChildViewModel Child { get; set; } 
    public GrandChildViewModel GrandChild { get; set; } 
} 

이것은 계층의 예입니다. 귀하의보기는 FatherViewModel만을 참조합니다. 그리고 컨트롤러는 FatherViewModel도받습니다. 당신이 좋아하는 HTML을 만드는 경우 ModelBinder를가 그 작업을 자동으로 수행합니다

<input type="text" id="Child_Name" name="Child_Name" /> 
+0

미안하지만 당신의 설명을 듣지 못했습니다. 당신은 나에게 동일한 참고 문헌이나 링크를 보내 주시겠습니까? – Atul

+0

이 링크는 여기에 다른 ViewModel이 들어있는 viewModel에 대한 답변이 있습니다. http://stackoverflow.com/questions/3267015/model-binding-for-a-viewmodel-containing-multiple-objects – TiagoBrenck

+0

아이디어는 계층 구조를 View Model로 가져오고 다른 모든 ViewModels의 속성을 포함하는 하나의 "아버지"가되도록 만듭니다. 이 "아버지"는보기에 변경되거나 입력 된 모든 정보를 전달할 책임이 있습니다. – TiagoBrenck

1

문제 1 : 그것은 입력을 렌더링

@Html.TextBoxFor(m => m.Child.Name) 

컨트롤러와 뷰 사이에 데이터를 전송하는 방법 언제 당신이 그런 계층 구조가 있습니까? 제가 부모님에게서 자식에게 데이터를 전달하면 중복이 많이 생기고, 한 아이를 바꾸면 모든 부모님이 변경해야합니다. 조회수가 직접 db에서 데이터에 액세스하는 것을 원하지 않으며 데이터가 컨트롤러를 통해서만보기로 전송되기를 원합니다.

관련 컨트롤러에 뷰를 등록하여 계층 구조를 무시하고보다 선형적인 접근 방법은 어떻습니까? 데이터는 Observer 또는 Listener 패턴을 통해 변경이 트리거되는 모델을 통해 수행 될 수 있습니다.

이렇게하면 중복이 발생하지 않습니다. 모든 것이 모델 또는 일련의 모델에서 중앙 집중화됩니다. 컨트롤러 또는 컨트롤러는 사용자 작업 또는 외부 이벤트가 발생한 후에 등록 된보기 목록에서 알림을 실행할 수 있습니다.

또한 뷰는 말한대로 데이터 소스에 액세스하지 않아야합니다. 여기에는 적어도 하나의 추상화 레이어가 있어야합니다. 컨트롤러가 중재자 패턴을 사용하는 경우 추가 데이터 계층의 인터페이스로 요청을 전달하여이를 처리해야합니다.

더 자세히 생각해 보면,보기를 통해 등록을 완료하는 것이 좋은 생각이라면 나는 생각하지 않습니다. 그래서 저는 이것을 별개로 유지할 것입니다. 직접 뷰를 초기화하거나 필요한 뷰를 반복 할 수있는 방법을 찾으십시오. 아마도이 단계를 자동화하는 일종의 공장을 통해 의견을 얻으십시오.

문제 2 : 이러한 계층의보기에서 컨트롤러로 이벤트를 전파하는 방법은 무엇입니까? PropertyChangeListener를 사용할 생각입니다. 보기가 fireProperty 컨트롤러가 조치를 취해야 할 경우 이벤트를 변경합니다. 컨트롤러가 이러한 이벤트를 수신하고 일부 작업을 수행합니다. 하지만 다시 계층 구조에 대해 이렇게하면 코드가 중복됩니다.

다시 선형 접근 방식을 채택 할 수 있습니다. 뷰가 등록되면 컨트롤러는 리스너를 추가 할 수 있습니다. 또는보기에서 디스패치 메커니즘을 통해 처리 할 수있는 일부 의미 스타일 메시지 (예 : doAction ("저장"))를 보낼 수 있습니다. 매개 변수를 전달하는 방법을 결정할 수 있습니다.

PropertyChangeListeners가 필요합니까? 제 말은, 당신은 그런 종류의 세밀도가 필요합니까?

각 패널 컨트롤러를 사용하려면하지만이 방법으로 내가 컨트롤러의 많은 을 종료합니다 :

내가 도움이 될 수있는 세 가지 아이디어가 있습니다. 이 뷰와 컨트롤러 간의 통신을 제공하는 중재자 디자인 패턴을 사용하십시오. 중역 수신자 &보기에서 모든 속성 변경 이벤트 을 수신 대기하는 알리미를 사용하고 관심있는 컨트롤러에 알립니다. 그러나이 단지 내 두 번째 문제를 해결한다 :이 막연하게 HMVC 같은 소리

. 이 접근 방식을 사용하면 각 하위 시스템에 대한 모델보기 컨트롤러의 트라이어드가 있습니다. 흥미로운 아이디어이지만 지저분해질 수 있으며 계층 구조가 어떻게 작동해야하는지, 조정/종속성이 어떻게 달성되는지는 분명하지 않습니다.

아마도 당신은 뷰, 모델 및 컨트롤러 중 하나가 누락되거나 올바르지 않은 경우 던져진 예외를 플러그인 할 수있는 앱의 각 모듈/하위 시스템에 대해 네 번째 중립 클래스를 가질 수 있습니다.

중앙 인식 자에 대한 아이디어에 따르면 다른 특정 기능 컨트롤러 나 더 많은 기본 동작에 대한 라우팅 메커니즘으로 작동하는 중앙 컨트롤러를 가질 수 있습니다.메시지가 어떻게 처리되는지는 귀하에게 달려 있습니다. 중앙 집중화가이 클래스의 디자인을 필수적으로 만들 때 스레딩에주의하십시오.

무엇을 하든지 가능한 한 간단하게 작업하십시오. 너무 많은 번거 로움없이 모델 및 컨트롤러로 테스트 뷰를 가질 수 있어야합니다.

+0

의견을 보내 주셔서 감사합니다. 또한 각각의 뷰 (패널)에 대해 하나의 컨트롤러를 만드는 것을 고려했지만, 앞서 언급했듯이이 방법으로 나는 많은 컨트롤러로 끝낼 것입니다. 바로 지금, One Dialog에는 TabbedPane과 6-8 JPanels가 두 개 정도있는 TabbedPane이 하나 있습니다. 이 방법을 사용하면 최소한 10 개의 컨트롤러로 끝납니다. 그리고 앞으로 추가 요구 사항을 위해 이러한 뷰 및 컨트롤러를 추가해야 할 수도 있습니다. – Atul

+0

TabbedPane을 사용하면 패널이 관련되어 있으므로 제어기 및/또는 모델이 있어야합니다. 응용 프로그램에서 어떤 일이 벌어지고 있는지 경찰이 알 수 있도록 중앙 집중식으로 처리해야합니다. 예를 들어 권한 시스템을 추가해야하는 경우를 상상해보십시오. 여러 클래스에 대한 시스템 전체 변경을 수행하는 것은 지루할 수 있습니다. 그래서 좋은 해결책 인 것 같습니다. –

+1

나는 지금 당장이 방법을 유지할 것이라고 생각한다. 그것이 어떻게되는지 보자. 귀하의 제안에 감사드립니다. 현상금은 당신의 도움이됩니다. – Atul

1

this HMVC Pattern을 사용했을 때 비슷한 문제가 발생했습니다. 예, 컨트롤러가 많이 있다는 의미에서 옳습니다. 그러나 코드에서 명확하게 분리 된 우려를 제공한다는 것도 사실입니다. 특정 응용 프로그램 특정 상위 컴포지트 위지트 (widget)를 작성하여 제어기 수를 제한 할 수 있습니다. 이 경우 계층 구조는 최대 2 ~ 3 단계까지 제한 될 수 있으며 컨트롤러를 연결하여 부모/자식 중 하나에게 이벤트를 위임 할 수 있습니다.

서버에서 데이터를로드하고 나면 세션 맵을 유지하여 어느 정도 구제 조치를 취할 수 있으며 easy access to frequently required data - 나별로 선호하지 않습니다.

개발 팀이 올바르게 이해하고 따르는 패턴은 매우 잘 작동합니다.