MVP 및 이벤트 기반 패턴에 익숙하다고 가정합니다.
MVP 및 이벤트 기반 패턴은 필자와 마찬가지로 책임감있게 분리되고 가독성을 높이도록 설계되었습니다. 그러나 이벤트 버스와 같은 라이브러리를 사용하면 이벤트를 쉽게 수행 할 수 있습니다.MVP 대 안드로이드 응용 프로그램에서 구동되는 이벤트
제 질문은 이벤트 및 구독자 패턴을 사용하여 메서드 책임을 분리 할 수 있다고 가정 할 때 응용 프로그램 아키텍처를 MVP로 변경하면 어떤 이점이 있습니까?
제 질문의 두 번째 부분은 MVP 패턴과 함께 이벤트 라이브러리 (예 : Eventbus)를 사용하는 가능성입니다.
편집 : 이것을 정리하고 단축했습니다.
귀하의 질문에 제시된대로 이벤트 기반 아키텍처와 MVC 아키텍처의 이점이 상호 배타적이라고 생각하지 않습니다. 이벤트 중심적이고 MVC 아키텍처와 일관성있는 코드를 디자인 할 수 있습니다.
이벤트가 발생하면 특정 이벤트가 발생할 때 실행되는 이벤트 처리기가 있습니다. 이벤트는 낮은 레벨 (마우스 동작 및 키보드 동작)을 시작하고 툴킷을 통해 상위 레벨 처리기로 전달됩니다. MVC는 핸들러의 위치를 구성하는 방법과 핸들러가 비즈니스 로직과 어떻게 인터페이싱하는지에 관한 것이다.
그래서 EventBus로 돌아갑니다. EventBus를 통해 모든 UI 이벤트를 가리키고 Model에 대한 모든 변경 사항이 다시 EventBus를 통해 View로 전달되면 EventBus 라이브러리가 MVC 아키텍처의 Controller에서 중요한 부분을 차지한다고 말할 수 있습니다.
MVC에 관해 생각할 때, 목표는 비즈니스 로직과 데이터를 데이터 표현에서 분리하는 것입니다. 이벤트 버스 (Eventbus)와 같은 것이 당신을 도울 수 있습니다. 컨트롤러 클래스는 모델에 EventBus를 묶고 UI를 다른쪽에 연결합니다. 완료되면 모델에 이벤트 스트림이 제공되었음을 알 수 있습니다. 이벤트 스트림이 GUI, 테스트 장치 또는 하드웨어 디버거에 의해 공급되는지는 알 수 없습니다.
이벤트 기반 아키텍처는 통신용입니다. 앱에서 느슨하게 결합 된 구성 요소간에 메시지/이벤트를 전송하는 데 사용합니다. 이점 : 구성 요소 추가/제거, 즉 게시자를 수정하지 않고도 구독자를 삭제하는 등의 골치 거리를 없앱니다.
MVP는 응용 프로그램 논리를 구성하기위한 것입니다. 비즈니스 로직을 GUI에서 멀리 유지하고 Presenter를 View에서 이벤트를 처리하는 중개자로 소개하는 데 도움이됩니다. 적절한 Model을 사용하여 모든 View 이벤트에 해당하는 비즈니스 로직을 진행하고 View에 데이터 서식을 지정합니다. 이점 : UI 로직과 Business Logic의 경계를 이끌어내어 구체적인 UI없이 비즈니스 로직 또는 두 가지 로직을 테스트 할 수 있습니다.
이제 첫 번째 부분 : 응용 프로그램 논리를 작성하는 방법과 논리가 응용 프로그램 (단위 테스트)에서 잘 구현되도록하는 방법에 대해 MV *는 EventBus가 아니라 사용자를 도울 수 있습니다.
두 번째 부분 : 네가 MVP와 함께 EventBus/MessageBus를 사용할 수 있습니다. 다른 것들을 담당하기 때문입니다. 예를 들어 MVP를 사용하여 Fragment를 View, Presenter 및 Model로 구성하고 EventBus/MessageBus를 사용하여 Fragment와 다른 Activity 사이의 통신, 응용 프로그램의 Fragment (s)를 사용할 수 있습니다.
MessageBus와 MVP를 모두 제공하는 실제 프레임 워크는 여기에서 있습니다 : http://robo-creative.github.io/mvp.어떻게 작동 하는지를 알고 싶다면 다음 지침을 읽어보십시오. http://robo-creative.github.io/mvp/presenter-features.html
잠시 동안 내 앱에서 이벤트 구동 코드를 사용했습니다. 이벤트 주도 코드가 MVC 패턴처럼 작동한다는 사실에 정말로 동의합니다. 여기서 MVC 패턴은 이벤트가 발생했을 때 응답이 어디서 왔는지를 뷰가 알지 못하는 곳에서 발생합니다. 하지만 제 질문은 이벤트 구동 아키텍처가 MVC 패턴으로 대체 될 수 있다는 두 번째 주장에 있습니다. 당신은 이벤트 버스를 사용한다면 (예를 들어.) 내 애플 리케이션에서 MVP 패턴을 사용할 필요가 없다고 생각합니까? – Mehrdad
이벤트 중심 MVC를 대체한다고 말하지 않았습니다. MVC와 함께 사용할 수 있습니다. 아마도 나는 Event Driven의 의미를 오해했을 것입니다. 즉, 낮은 수준의 이벤트 (타이머 오버플로 또는 사용자의 버튼 클릭)는 비즈니스 논리를 포함하여 상위 계층까지 퍼콜합니다. 높은 수준의 코드는 조작 순서를 예측/제어 할 수 없습니다. 실제로 일부 작업은 다른 스레드에서 동시에 실행할 수 있습니다. 그 반대는 어떤 종류의 폴링 루프 일 것입니다. 거기서, 타이머와 버튼의 상태는 무언가가 일어날 때까지 반복적으로 체크되고 루프는 핸들러를 호출합니다. – Teto
나는 이것을 누군가와 이야기하고 있었고, 나는 아직도 너를 오해 할 수도있다. 이벤트 버스를 사용하면 "이벤트가 발생하지 않는"프로그램을 만들 것을 제안 하시겠습니까? 아니면 MVP가 아닌가요? 이벤트 구동 방식이 아닌 곳이라면 어디서나 UI 툴킷을 찾을 수 있습니다. 그리고 EventBus는 모델에서보기를 감추는 데 먼 길을갑니다. 그렇다면 어떤 혜택을 얻지 못할 것이라고 생각하십니까? 그리고 왜? – Teto