적절한 Model-View -_____ 디자인

Model View Controller, Model View Presenter, Model View ViewModel 등에 대해 읽었으며 일반적으로 기본 개념은 이해하기가 매우 간단 해 보입니다. 가능한. 디자인 초콜릿에 논리 땅콩 버터를 넣지 않음. 멋지다.

문제는 여전히 그 세 번째 부분에 대해서는 약간 모호합니다 ... 모델이 아닌 관점입니다. 누구나 전화해야 할 것,해야 할 일, 올바른 것, 명백한 잘못에 대한 자신의 아이디어를 가지고있는 것 같습니다. 발표자가 ViewModel이 될 때와 View가 안 될 시점을 알아 내려고 노력하고 있습니다. 발표자의 직업이기 때문에 그렇게하지 마십시오.

나는 짓밟고있다.

이미 다른 사람들이 그들 사이의 차이점을 설명 해달라고 요청하기보다는 이미 몇 번이고 반복되어 왔기 때문에 (알다; 내가 셀 수있는 것보다 더 많은 기사를 읽었 기 때문에)-나는 내가 함께 모은 모델의 프로그래머는 거의 없다.

즉, 이 디자인을 무엇으로 분류하고, 더 중요 하게는 이것에 대해 분명히 짜증나는 것을 보았습니까? 물론, 이것이 정말로 견고한 디자인이라면 내가 잘하고 있다는 말을 듣고 싶습니다. 그러나 나는 칭찬에 대한 확실한 조언을 많이 받고 싶습니다.

참고 : Model-View-의 신비한 세 번째 부분에 "다리"를 사용할 예정입니까? 그것이 무엇이어야하는지에 대한 잠재 의식적인 제안을 피하기 위해.

모델

• 데이터에 대한 권한입니다.
• Bridge에서 요청 된 변경에 대한 정보를받습니다.
• 데이터와 다른 데이터의 관계에 대한 모든 논리를 포함하고 수행합니다.
• 데이터가 변경 될 때 Bridge에 알립니다 (Bridge가 관심을 보인 데이터에 대해). 문구 편집 : 외부 가입자 (아무것도 모르는)가 가입자의 상태 또는 계산 결과를 모니터링 할 수 있습니다.
• 보기에 대한 지식이 없습니다.

전망

• 사용자에게 데이터를보고 조작하는 방법을 제공하는 것과 관련이 있습니다.
• Bridge에서 데이터 업데이트에 대한 정보를받습니다.
• 사용자에게 데이터 및 컨트롤을 표시하는 방법에 대한 모든 논리를 포함하고 수행합니다.
• 사용자가 모델에 영향을 줄 수있는 작업을 수행했을 때 브리지에 알립니다.
• Bridge에 관심있는 정보를 알려줍니다.
• 모델에 대한 지식이 없습니다.

다리

• 모델과 뷰 사이의 코디네이터 및 번역기입니다.
• 모델과 뷰 사이에 전달되는 정보의 형식을 적절하게 변경합니다.
• "누가 무엇을 알아야 하는가"에 대한 정보를 보유합니다.
• 모델과 뷰에 대한 지식이 있습니다.

추가 사항

• 보다 복잡한 프로그램에서는 여러 모델이있는 것이 일반적입니다. 이 상황에서 Bridge는 일반적으로 여러 모델 간의 조정 / 번역 작업을 수행하므로 프로토 타입 / API / 디자인 모델을 구축해야하는 권한이됩니다. (예를 들어, 카드 게임 프로그램을 구축하고 다른 데크 셔플 링 모델을 구축하려는 경우 Bridge와의 적절한 통신에 필요한 기능을 결정하기 위해 Bridge를 사용해야합니다.)
• 뷰와 모델이 하나만있는 작은 간단한 프로그램에서는 브리지가 어느 쪽에서 사용할 수있는 기능을 "가정"하는 것이 일반적입니다. 그러나 프로그램이 더욱 복잡 해짐에 따라 뷰와 모델은 비효율 성과 버그가있는 가정을 피할 수 있도록 해당 기능을 브리지에보고하는 것이 좋습니다.

나는 그것을 덮고 있다고 생각합니다. 꼭 사용하려는 디자인에 대해 궁금한 점이 있으면 언제든지 제안 해주십시오.

언제나 그렇듯이 시간을 내 주셔서 감사합니다.

당신의 문구

"모델과 뷰 사이의 코디네이터이자 번역가입니다."

Bridge가 MVP 아키텍처에서 발표자임을 나타냅니다.

MVP와 MVC는 MVP에서만 Presenter 만 모델을 관찰하는 반면 MVC에서는 View가 모델을 직접 관찰 할 수 있다는 점을 제외하고는 매우 유사합니다 (발표자가없는 "브리지").

모델 책임

"데이터가 변경 될 때 Bridge에 알립니다 (Bridge가 관심을 보인 데이터에 대해)."

어쩌면 잘못 표현되었거나 실수 일 수 있습니다. 모델이 브리지 / 발표자 / 컨트롤러 또는 뷰에 종속되는 것을 원하지 않습니다. 대신 Observer 패턴, 이벤트 또는 반응성 프로그래밍을 사용하여 Bridge가 모델의 변경 사항 을 구독 할 수 있습니다. 그런 다음 책임을 다음과 같이 바꿀 수 있습니다.

"외부 가입자 (아무것도 알지 못하는)는 가입자의 상태 또는 계산 결과를 모니터링 할 수 있습니다."

모델이 컨트롤러 또는보기에 종속되지 않은 경우 테스트하기가 훨씬 쉽고 휴대 성이 훨씬 뛰어납니다.

혼란스럽게 생각하는 것 중 하나는 일반적으로 model-view-controller라고 불리는 완전히 다른 두 가지 패턴이 있다는 것입니다.

smalltalk에서 구현 된 원본이 있으며 로컬 GUI 시스템에 유용하며 web-mvc로 생각하는 경향이 있습니다. 웹 MVC는 컨트롤러가 클라이언트에있는보기 (아마도 html로 렌더링되었거나 아약스를 통해).

귀하의 설명은 web-mvc의 대부분의 정의에 포함되는 것처럼 들립니다.

프로그래밍 커뮤니티에서이 정확한 명명법에 대해 많은 토론이 있습니다. 아무도 많은 것에 동의하지 않는 것 같습니다.

나를 위해 다리가 뷰에 연결되는 방식이 대부분 이름을 결정합니다.

• 브리지 당 뷰 모음이있을 수있는 경우 브리지는 컨트롤러입니다.
• 브리지 당 항상 하나의 뷰가있는 경우 브리지는 발표자입니다.
• 뷰당 브리지 모음이있을 수있는 경우 브리지는 뷰 모델입니다.

때로는 상황이 그렇게 명확하지 않습니다. 예를 들어, 발표자는 여러 서브 뷰로 구성된 컴포지트 뷰에 연결되거나 해당 뷰에 대한 지식없이 컨트롤러를 만들 수 있습니다. 그럼에도 불구하고 내 규칙은 좋은 출발이라고 생각합니다.

부수적으로, 나는 다음과 같은 책임을 묶고 싶다.

모델

주요 책임 : 데이터 유지
보조 역할 : 업데이트 확인, 관찰자에게 업데이트 알림

전망

주요 책임 : 현재 데이터
보조 역할 : 입력 수락, 현재 UX

다리

주요 책임 : 데이터 업데이트
보조 역할 : 입력, 동기화 데이터 및보기 정리

제안 된 패턴은 표면적으로 정확하고 작은 인스턴스에서는 의심 할 여지없이 작동하지만 앱이 복잡해지면 무엇이 무엇을 업데이트하고 누가 어디에서 듣고 무엇을 시도하는지 확실하지 않은 문제에 직면하게됩니다 많은 뷰 내에서 서로에 대한 액세스가 필요한 모든 사람 등에서 많은 모델을 제어

다음 패턴을 사용하여 아이디어를 확장하는 것이 좋습니다 (Amy Palamountain의 Enemy of the State 에서 발췌 ).

모형

• 데이터 저장소와 상태 동기화
• 새로운 / 업데이트 된 데이터의 유효성 검사 처리
• 상태 변경시 이벤트 발생

견해

• 렌더 템플릿
• 모델 이벤트 처리
• DOM 이벤트 처리
• Model과 DOM 간의 상호 작용을 중재

컨트롤러

• 관리 기껏해야 몇 모델 및 뷰의를
• 컨테이너 내에서 조회수 추적

모듈

• 컨트롤러와 해당 뷰 및 모델의 논리적 그룹
• 테스트 가능
• 작고 유지 보수 가능 (단일 책임)
• 컨트롤러를 통해 포함 된 뷰 및 모델의 상태와 이벤트를 조정합니다.
• 자체 뷰를 무료로 제공
• 뷰를 표시 할 위치 를 자유롭게 선택할 수 없음

레이아웃 관리자

• 레이아웃 구성을 담당
• 모듈에서 컨텐츠를 표시 할 수있는 영역을 사용하여 DOM에서 애플리케이션 쉘을 정의합니다.

디스패처

• 글로벌 PubSub 스트림을 통해 이벤트 청취
• 이벤트를 기반으로 새 모듈을로드 할 책임
• 로드 된 모듈을 레이아웃 관리자에게 전달
• 전체 모듈 수명 관리 (작성, 정리, 캐시 등)
• 이벤트 예 :
  • 경로 변경 (초기로드 경로 포함)
  • 사용자 상호 작용
  • 서버 측 상태 변경 등으로 인해 모델 이벤트에서 발생한 모듈 이벤트

신청

• 전체 설정을 담당하며 다음과 같은 것을 인스턴스화합니다.
  • 디스패처
  • 라우터
  • PubSub 스트림
  • 로거
  • 기타

이러한 종류의 패턴을 사용하면 응용 프로그램을 작성 가능하고 단위로 테스트 할 수 있으며 시간이 지남에 따라 Bridge가 쌓을 복잡성을 제거하고 우려 사항을 멋지게 분리 할 수 ​​있습니다.

Amy가 지적한대로 : 클라이언트에서 서버를 구축하지 않도록주의하십시오. "MV * 프레임 워크를 만들고 있으므로 반드시 ___해야합니다"라는 교리에 빠지지 않도록주의하십시오. 대신,이 모든 아이디어 (여기서 다른 답변)를 사용하여 응용 프로그램 및 팀에 가장 적합한 것을 찾으십시오.

Amy Palamountain의 연설 Enemy of the State (이러한 아이디어가 나온 곳)를 보거나 최소한 연설에서 슬라이드 를 살펴 보는 것이 좋습니다 .